51

(3 replies, posted in Juicebox-Pro Support)

Steven, you're getting punchy, or maybe you had a senior moment, if you're old enough for that.

You meant to say that the default for imagePreloading is PAGE, not NEXT, right?

Bill

52

(6 replies, posted in Juicebox-Pro Support)

I don't know whether this will help the poster, but for what it's worth...

I use two products (and which one depends on exactly what I'm doing)  in the course of getting photos from my camera to my PC:

1) jhead, free, http://www.sentex.net/~mwandel/jhead/
2) Downloader Pro, pretty cheap, http://breezesys.com/Downloader/index.htm

Among other things, these two pieces of software allow you to automatically name photos based on the image-capture date/time in the EXIF info, either during actual download or after the fact. I generally don't bother, but you can also append a string. I imagine there are other apps that perform similar duties, especially in the non-free category, on both PCs and other operating systems.

Thus, my images get named 2014-09-04-14-59-59.jpg, for instance. If I'm downloading from another camera and I happened to have taken another picture at the same second (doesn't really happen), it would get a (2) or A or something right before the period. Adding a string option would yield something like 2014-09-04-14-59-59-such-and-such-project.jpg.

The point is, if you (re)name pics based on when they were taken, software that later sorts only by file title will also have your pics sorted by image-capture time.

I don't mean to insult anyone if this info is not applicable in your particular case, or if you already knew about this sort of thing, etc.

Cheers,

Bill

53

(17 replies, posted in Juicebox-Pro Support)

gfs:

You raise an interesting point. Are you thinking that Juicebox should add more screen sizes, i.e., in addition to Small and Large, maybe an Extra Large mode? And then have different groups of images available to be shown for each? Small screen mode doesn't currently send smaller images than Large screen, right?

I do have a question for you. I have all of my 60-some galleries coded to preload the Next image, instead of All. I'm just curious regarding your rationale of adding wait time for that first image to show up, via a potentially large preload stream. Me, I feel that it's better to give the viewer something in short order, even if that potentially means that the remaining images can't be shown as fast. And actually, my assumption -- or at least my hope -- is that the user will look long enough at each image that the next one will have time to have been preloaded.

Just curious to see under what circumstances I may be missing something.

Regards,

Bill P.

Yep, I follow you. Thanks for the clarification, and for moving my question out of that thread.

Bill

Steven wrote:

This sounds like you may be experiencing a bug which has been fixed.
Please download the latest version of Juicebox-Pro v1.4.2 (using the link from your purchase email) and you should no longer experience this issue. Please see the Upgrading Juicebox support page for details.

Steven: sorry about this minor thread digression, but I see only one bug fixed listed in the Version History page for 1.4.2. Is that not a complete list? I ask, because not using Flickr I was planning on skipping that release.

Cheers,

Bill P.

56

(4 replies, posted in Juicebox-Pro Support)

Steven wrote:

@wspollack

No. jAlbum has the ability to save a project's settings (very much like saving a preset in JuiceboxBuilder-Pro) which you can then apply to a future project.
However, there is no such functionality in the Juicebox plugin for Lightroom and you cannot load an existing Juicebox gallery in Lightroom to edit it (which, if it could be done, you would do to simply load the configuration options and ignore the images).

Modifying the plugin's 'config.xml' file is probably the easiest way to ensure that certain configuration options are applied to all galleries created by the plugin.

OK, thanks for the explanation.

57

(4 replies, posted in Juicebox-Pro Support)

I don't know anything about the LR plugin, so I may be way off base here. However, FWIW, I use JB Pro with jAlbum, and like to keep the same settings for each gallery. What I did was save my preferred setup in jAlbum, with no pictures. When I want to make a new gallery, I open that jAlbum gallery, drag in new images, and then do a "Save As" (my new gallery name), and generate and upload my new page.

This kind of template-then-Save-As approach won't work with LR?

Steven:

Mark this "[Solved]," please. The server and connection speeds were red herrings. Well, they may have come into play -- you know infinitely more about this sort of thing than I do -- but they weren't the real problem.

A little over a month ago, I switched from a free anti-virus, etc., system to a paid suite from Bitdefender. It turns out that if you have the setting Privacy --> Antiphishing --> Show Bitdefender Toolbar set to "On," Bitdefender -- and, yes, I find this hard to believe myself -- inserts code into (at least some) downloaded web pages! In this particular case (my experimenting very carefully this morning with http://www.billanddot.com/victory-xct/ ), it changed...

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
        <!-- saved from url=(0014)about:internet -->
<head>
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
            
                <meta name="apple-mobile-web-app-capable" content="yes" />
            <script type="text/javascript" src="res/juicebox/jbcore/juicebox.js" charset="utf-8"></script>
            <script type="text/javascript"><!--//--><![CDATA[//><!--
                            new juicebox({
                                backgroundColor : "rgba(51, 51, 51, 1.0)",
                                configUrl: "config.xml",
                                containerId: "juicebox-container",
                                galleryHeight: "100%",
                                galleryWidth: "100%",
                                themeUrl: "res/juicebox/jbcore/classic/theme.css"
                            });
            //--><!]]></script>
            <style type="text/css"><!--/*--><![CDATA[/*><!--*/
                body
                {
                    background-color: #333333;
                    margin: 0;
                }
                body, html
                {
                    overflow: hidden;
                }
            /*]]>*/--></style>
            <title>2012 Victory Cross Country Tour</title>
        </head>
        <body>
                    <div id="juicebox-container"></div>
</body>
    </html>

...to, in one such test (scroll to the bottom of the code)...

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
        <!-- saved from url=(0014)about:internet -->
<head>
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
            
                <meta name="apple-mobile-web-app-capable" content="yes" />
            <script type="text/javascript" src="res/juicebox/jbcore/juicebox.js" charset="utf-8"></script>
            <script type="text/javascript"><!--//--><![CDATA[//><!--
                            new juicebox({
                                backgroundColor : "rgba(51, 51, 51, 1.0)",
                                configUrl: "config.xml",
                                containerId: "juicebox-container",
                                galleryHeight: "100%",
                                galleryWidth: "100%",
                                themeUrl: "res/juicebox/jbcore/classic/theme.css"
                            });
            //--><!]]></script>
            <style type="text/css"><!--/*--><![CDATA[/*><!--*/
                body
                {
                    background-color: #333333;
                    margin: 0;
                }
                body, html
                {
                    overflow: hidden;
                }
            /*]]>*/--></style>
            <title>2012 Victory Cross Country Tour</title>
        <script type="text/javascript"></script><link rel='stylesheet' type='text/css' href='/B1D671CF-E532-4481-99AA-19F420D90332/netdefender/hui/ndhui.css' /></head>
        <body><script type='text/javascript' language='javascript' src='/B1D671CF-E532-4481-99AA-19F420D90332/netdefender/hui/ndhui.js?0=0&amp;0=0&amp;0=0'></script>
                    <div id="juicebox-container"></div>
</body>
    </html>

I downloaded and installed a couple of sniffer programs, but all I had to do was a simple View Page Source to discover this. Sorry about that, but who knew?

BTW, I was experimenting with the latest versions of Chrome and Firefox. What I was doing this morning was clearing each browser's history (for "Today" in FF, my default browser, and since "the beginning of time" in Chrome), and then attempting to load that page. In my testing this morning, I was consistently getting that problem, with Chrome displaying that error message and FF just sitting there, not displaying anything except the background color. As before, an F5 then eliminated the problem each time (in either browser). Following that testing, turning that option off in Bitdefender left the HTML code alone, and the problem went away.

Searching Bitdefender forums reveals complaints about this "feature," but nothing I could find was terribly recent, nor did I stumble across any post where someone reported that it can prevent a page from loading properly. I'll look a bit more, and add my own post there if I don't find anything like that. (Bitdefender seems like a nice suite in other respects, BTW, and gets good marks from testing services, is very quick in its scans, and was cheap enough. And I believe I'm just past the get-your-money-back period, so I guess I'll keep it.)

Bottom line: if anyone else gets that error message, ask if he or she is using Bitdefender and has that toolbar option on, and have the poster take a look at the page source in the browser.

Thanks, as always, for your time and support.

Bill

Steven, thanks for your help. I tried suggestion 2 (see http://www.billanddot.com/victory-xct/i … ction.html ), but it doesn't load at all -- no error message, refresh doesn't help.

Re suggestion 1, I don't really understand it.

I use Firefox as my default browser, but my experimenting with Chrome 33 brought up this problem. With Chrome, my results -- with the normal code (I'm using http://www.billanddot.com/victory-xct/ now) -- are just plain inconsistent. I run Chrome, enter that URL, and often get that error message. Then I click on refresh, and it's always OK. Then I completely shut down Chrome, wait a bit, and run Chrome again. And repeat the test; sometimes it works OK, and sometimes I get the error.

I have a high-speed fiber-optic connection to my house (c. 60mbps download, c. 30mbps upload). My hosting service is Bluehost.com, a couple thousand miles west of me. I pay the minimum, so I don't have a dedicated server machine, but the load times of all my sites -- after I clear my cache and history -- seem reasonable to me.

Yeah, this looks like a timing issue to me, but I'm not sure regarding the timing of what.

Bill

Using Chrome (33.0.1750.117) in particular, on my PC (Vista Home Premium SP2 32-bit), if I attempt to look at some of my Juicebox galleries I get a blank screen with the following message:

Juicebox Error: Cannot find div with id: "juicebox-container"

I also sometimes seem to encounter this problem in Firefox (27.0.1), although Firefox does not seem to deliver this message, but rather seems to just not load the page.

This problem goes away with a simple refresh (F5) of the gallery in question. I have cleared the cache, etc., in Chrome completely, to no avail.

These pages pass W3C's HTML and CSS validators, and I am using the latest version of JB.

A sample gallery, one I've encountered this problem with, is http://www.billanddot.com/victory-xct-p … ide-cover/

I was unable to find a similar report using the search feature here, but maybe I missed something. Any suggestions, comments, similar reports?

Cheers,

Bill

61

(8 replies, posted in Juicebox-Pro Support)

laird44 wrote:

Thanks. I'll try it.

Laird: yep, with Steven's help, I've been doing this ever since JB was releassed, on about 60 different pages. Take a look at http://www.billanddot.com/victory-xct/ , for instance; clicking the home pic -- equivalent to your logo -- take the user to my home page. I think that's what you're trying to do, if I understand your question correctly.

Bill P.

Steven wrote:

when you click the Info "off" on galleries that have the button shown, the navigation overlay is still visible if the mouse is moved off screen.

This should not be the case.
In this gallery of yours (http://www.billanddot.com/burgman/), if 'Info' is OFF and you mouse-out, only the thumbnail navigation buttons (not on the image overlay) and the Button Bar remain visible. (The entire Button Bar will always remain visible when showInfoButton="TRUE".)
Do you have a test gallery which demonstrates the behavior you describe? I'll gladly take a look.

I think I'm just not using the proper terminology, is all.

What I meant is that I sort of expected that if you have a gallery with showInfoButton=TRUE, and then you click that icon to its Off state, then the navigation bar area -- that thingy with the seven icons in the upper right -- would disappear if you moved the mouse to, say, the taskbar... i.e., exhibit the same behaviour that a gallery does when you'd set showInfoButton=FALSE (whose six-icon navigation thingy disappears on mouse-far-away movement).

That's a long sentence, but does it make my comment any clearer?

Thanks for the link. I've just been reading that info a few times, and I guess I understand it. Still seems a little odd to me, though, e.g., when you click the Info "off" on galleries that have the button shown, the navigation overlay is still visible if the mouse is moved off screen. But thanks for the explanation; the software is working as intended, I gather.

Bill P.

I recently noticed what I believe is a minor bug, or a quirk... or at least I don't think this is intentional.

I have several cases in which I have identical (except for the pictures within them) non-embedded galleries, except that:

1) some of the galleries have:
    A) showInfoButton=FALSE
    B) captionBackColor="rgba(0,0,0,0)"
    C) no caption text in any of the pictures

2) while the other galleries have:
    A) showInfoButton=TRUE
    B) caption text in many of the pics;

In the first group of galleries, if you move your mouse outside of the browser frame -- i.e., to the Windows taskbar area or to the browser's menu area (or outside of the browser application itself, if it is not maximized) -- the navigation bar and my home-page icon disappear while the mouse is thus moved. However, for the second group of galleries, such mouse movement has no effect at all, i.e., the navigation bar and home icon remain visible. It is that visibility difference that I am questioning.

Note that both sets of galleries still have focus after moving the mouse out of the browser area. That is, even if the navigation bar is not shown in the "showInfoButton=FALSE" galleries after the mouse is moved, say, to the taskbar area, you can still use the Home, End, and left- and right-arrow keys to look at different images in the loaded gallery.

This is the environment for me:

Juicebox Pro 1.3.3
jAlbum 11.6.4
Vista Home Premium SP2 32-bit SP2

The jAlbum Juicebox settings checked are:

Show Open Button
Show Thumbnails Button
Use Fullscreen Expand
Display Captions

The jAlbum Pro-area options are, with the exception of the two options discussed above:

galleryTitlePosition=NONE
textColor=FFFFFF
imagePreloading=NEXT
imagePadding=10
showImageNav=FALSE
maxThumbColumns=50
showAutoPlayButton=TRUE
showNavButtons=TRUE
showBackButton=TRUE
backButtonText=<a href="http://www.billanddot.com/index.htm" target="_top"><img src="http://www.billanddot.com/house_2.png" width="32" height="32" alt="Home (Bill &amp; Dot's Excellent Pages)"></a>
backButtonUrl=http://www.billanddot.com/
backButtonPosition=OVERLAY
showSplashPage="NEVER"

Two such differing galleries are, for example:

http://www.billanddot.com/burgman/
http://www.billanddot.com/valkyrie/

Tested using the following browsers:

Firefox 25.0.1
IE 9.0.8112.16421
Opera 18.0
Safari (for Windows) 5.1.7

Thanks for any thoughts on this.

Cheers,

Bill P.

Thanks for the code snippet. Just setting debugmode seems fine to me; after all, if the viewer can click on icons to change the behavior, I don't mind his or her changing the behavior via a URL.

Thanks for your time and effort, Steven.

Cheers,

Bill P.

Ah, I missed that -- thanks, Steven.

Are there any other side effects to setting debugmode? I searched that page, and couldn't find any other mention of it.

Bill

Steven (et al.?):

For a non-embedded gallery, with enableDirectLinks at its default FALSE value, it's possible to start viewing at a certain image. For instance, as you note at http://www.juicebox.net/support/config_options/ , you can use a link such as http://www.mysite.com/mygallery/#12 to go directly to the twelfth image.

My question: is there a way to also temporarily set some of the options in a hyperlink, along the lines of, say, http://www.mysite.com/mygallery/#12?sho … Load=FALSE ?

For instance, if I want to direct someone to a just one particular image in one of my galleries, I provide a link such as http://www.mysite.com/mygallery/#12. For general viewership, I have showThumbsOnLoad=TRUE, but in this ad hoc case I'd just as soon not have the thumbnails appear (unless the navigation icon is clicked, i.e., the reverse of my default on-load setup). Anything like this possible in a URL?

Cheers,

Bill P.

68

(4 replies, posted in Juicebox-Pro Support)

Hey, thanks banaandigitaal for asking and Steven for answering this question. I never thought to ask, but -- as I mentioned in a recent thread -- I hardly ever add captions. But I use the image numbering, so this perfect for me.

I also now, in the Pro options area, just changed showInfoButton=TRUE to showInfoButton=FALSE. With that caption area color bar now gone, I find I don't have a need to have the "i" nav button present; before, all it did was remove that bar, the image numbering, and my home-page (back) icon (which I have in the upper left). This has the added benefit, to me, of making that navigation bar smaller (narrower), which sometime overlayed some very wide images; this change reduces that likelihood.

Now to revise a bunch of galleries...

Thanks,

Bill P.

OK, understood. Thanks for your help.

Steven: just emailed you the photo. If you're experimenting with it, you should make a copy or two of it first.

All it takes to correct this problem, with this file, is to put it in a jAlbum Juicebox gallery, and blank out the area below the picture -- the area that normally (for me, anyway, with whatever jAlbum settings that I have) just shows the file title, if you haven't entered a caption. Put another way, just add a blank caption to it; once you do that, the gallery generates (and previews) just fine... and the image appears to be permanently fixed. That is, I did that to it in one gallery, and then I dragged the same image from its location on disk to another test gallery; this (second) time, there was no caption present (and, as with the other images, just the file name appeared below the pic).

What I emailed you is a copy of that original image. This copy still has whatever bad metadata -- which, coincidentally(?), appears to start with "METADATA" -- that the original had, before I blanked the original's caption area. This emailed copy will still appear with "METADATA..." as a caption, if dragged onto a jAlbum screen.

As a side note, I rarely enter any captions. I think only two or three of the approx. 60 Juicebox jAlbum galleries I have up actaully have any captions. I just leave that Display Captions set, anyway, as a default template, which is why I bumped into the problem in this latest gallery (where, as usual, I wasn't adding captions).

Cheers,

Bill

Steven, it turns out that the problem is with a particular photo. In jAlbum, the photos are displayed in the gallery grid with their file titles listed under them. For this one particular image, instead of its file title (2013-09-07-12-52-01.jpg), what is displayed is:

METADATA-START [a bunch of unprintable, unpasteable, etc., characters follow -- perhaps 5,000 in all, which mostly appear as ...UUUUU..., and concluded by:] METADATA-END

As I wasn't paying attention, and as I working with about 50 photos, and as only the start of ("METADATA-START... [some gobbledygook]") is shown in the grid with all the other photos, I didn't notice that in the gallery I created yesterday.

Working with a test gallery today, I noticed it. If that photo is left in the test gallery, and if Display Captions is set, it breaks the generation of the xml file. That file abruptly ends thusly...

        <image imageURL="slides/2013-09-07-12-52-01.jpg" thumbURL="thumbs/2013-09-07-12-52-01.jpg" linkURL="hi-res/2013-09-07-12-52-01.jpg" linkTarget="_blank">
            <title></title>
            <caption><![CDATA[METADATA-START

...wherever that particular photo is placed in the gallery. That is, there is no...

        </image>

</juiceboxgallery>

...and neither are any subsequent photos processed.

If Display Captions is unchecked, that file is processed fine, wherever it occurs among the other photos:

        <image imageURL="slides/2013-09-07-12-52-01.jpg" thumbURL="thumbs/2013-09-07-12-52-01.jpg" linkURL="hi-res/2013-09-07-12-52-01.jpg" linkTarget="_blank">
            <title></title>
            <caption></caption>
        </image>

That particular photo is one of three, among the 51 photos in that gallery, that originated from a Samsung S4 phone's camera (which I don't own or currently have access to). The other two were handled just fine; I experimenteed with a test gallery today, using all 50 photos, i.e., the same photos, including the two other Samsung pics, but minus the troublesome one.

All three of these photos are 4128x2322 to start with (my gallery reducing them to 1024x1024, Link to hi-res* via scaled images, Copy originals). The problem one is 2477KB, while the other two are 1848KB and 1602KB. Incidentally, the problem one lists normally in terms of title, 2013-09-07-12-52-01.jpg, in Windows Explorer and any of several programs with which I've opened it. I've also done a Windows (Vista Home Premium 32-bit SP2) drag-and-copy several times, and the copies exhibit the same behavior. I also saved a version of it that I personally cropped (using Faststone Image Viewer), and that, too, appears with this strange title in jAlbum.

So, what I think we have here is some odd combination of events. Perhaps something is corrupted with this one particular file, and perhaps jAlbum needs some additional defensive coding, as well. I attached the photo to a POP3 email, which I then sent to myself, via a POP3 mailer, to a gmail address, retrieved it, and saved it as a new title. That new file still presents this jAlbum problem, so I think if you (or someone at jAlbum) want to take a look at it, I think that I can preserve the problem even via email; let me know.

Cheers,

Bill

Steven:

I attempted to generate a new gallery earlier today, using jAlbum 11.5, Juicebox Skin Version 1.3.2.0, and got the preview to hang (Firefox) or the XML Not Found error (IE). By a process of experimentation and elimination, I determined that the error was the result of my checking the Display Captions box in the Juicebox settings window in jAlbum. This was the case whether or not I actually had any captions to display. Unchecking this box solved the preview problem, and uploading through jAlbum then also resulted in a working web page.

I have the following Pro options listed in the settings box...

galleryTitlePosition=NONE
imagePreloading=NEXT
imagePadding=10
showImageNav=FALSE
maxThumbColumns=50
showAutoPlayButton=TRUE
showInfoButton=TRUE
showNavButtons=TRUE
showBackButton=TRUE
backButtonText=<a href="http://www.billanddot.com/index.htm" target="_top"><img src="http://www.billanddot.com/house_2.png" width="32" height="32" alt="Home (Bill &amp; Dot's Excellent Pages)"></a>
backButtonUrl=http://www.billanddot.com/
backButtonPosition=OVERLAY
showSplashPage=NEVER

...and the following additional boxes checked:

Show Open Button
Show Expand Button
Show Thumbnails Button
Use Fullscreen Expand

Your thoughts on this?

Cheers,

Bill

[Edit: forgot to mention that this was my first use of 11.5, which I had downloaded and installed a few minutes before that.]

OK, thanks, Steven.

Bill

This comment may or may not be related to any future changes regarding small-screen navigation of thumbnail pages, but I noticed the following quirk: if you load that page, and then the very next thing you do is press the right-arrow key, the first picture load... behind the thumbnails (i.e., you can see it on the top and bottom of the screen, and in the areas between thumbnail images. If you continue using only the arrow keys, this behavior continues. If, instead, you click on one of the thumbnails, the main image appears and the thumbnails disappear.

Just thought you folks might be interested in this, if you haven't noticed it already.

Cheers,

Bill

75

(496 replies, posted in Juicebox-Pro Support)

pinamac wrote:

...
I think I have to replace all the jbcore directories for an upgrade.
...

If this is not too geeky for you, and you have access to your web server, you may be interested in a python script I wrote about a year ago: see http://juicebox.net/forum/viewtopic.php?id=147 .

I use this every time a new Juicebox version is released. Once I copy a fresh /jbcore/ directory to my host, it takes just a few seconds to find and update about 60 galleries I've created with JB. (Yes, I'm aware that you can have all your JB galleries point to a common, single, jbcore directory, but I don't do that.)