By curiosity, can you make screenshots? Thanks!
Good idea. Here's a page with three of these text frames. The one on the left has the entire stroke. The upper-right has only a partial right-side stroke, and the one on the lower-right is completely missing the bottom stroke. [Yes, that frame is overset, and missing the last couple of words, but that doesn't account for it.] I wonder... I haven't been compulsive about setting the sizes of the frames to precise full-pixel dimensions. Nope. Just checked. The "chemical reaction" frame is precisely 378px wide, and the "digest" frame is precisely 98px tall. Both have the stroke aligned to the inside.
What device and reader/reader version used?
MacBook Pro, ca.2011, OSX 10.10.1. The page screenshot is from iBooks. Readium (Chrome extension) behaves almost the same way. For the page shown, the bottom-right text frame stroke is complete, but the other incomplete frame strokes in the document are as in iBooks. Readium also plays the Flash animations that I imported into the EPUB. So almost, but not quite, the same.
If you put the .epub file (or part of it with a page with problem) on Dropbox, I can take a look!
OK! I see the problem, e.g. page 14.
Can you send the chapter ID file or make a simple ID file of this page 14, and dropbox it? Thanks.
Again, done. I think....
No link email!
Perhaps I got it right this time....
Bad news, imho!
I've copied/pasted a problematic block in a new ID file, exported it to epub FXL: Same problem.
I've opened the epub file with oXygen: the png file is correct.
So bug?! Annoying! Sorry not to be more helpful!
Ah, well. I suppose it's what Robert A Heinlein predicted decades ago: computers get enough processing power and they acquire consciousness, which begins with playing practical jokes.
What we could call "humor" or "cynicism"?
@Obi-wan – I can only guess what's going wrong with that:
Is the container that holds the png too small to show the whole image?
One pixel or two pixels too small?
How are the strokes defined in InDesign?
1. Grow to outside and inside of the path of the text frame?
2. Grow to outside only?
3. Grow to inside only?
Does that make a difference?
Humor indeed! In any event, I've had some luck fixing the problem by taking care to make the dimensions of the text frames integral numbers of pixels, and the X,Y coordinates of those frames also integral numbers of pixels. This has helped a number of the text frames that I've checked. The epub readers may have trouble displaying fractions of pixels if they have been optimized for 72 or 150 dpi display. Perhaps it's simply a matter of the designer actually paying attention to the performance characteristics of the target reader. If so, it's "obvious" in retrospect.
I've now been through my textbook, inserting the html5 animations and cleaning things up. For the text frames, ID has exported png files that are not quite correct. If the right border is missing, it is because the png file is a bit too wide. I can correct the png file in Illustrator to make it a bit narrower; the border reappears if I edit it correctly. If the bottom border is missing, the png file is a bit too tall. I can see no obvious reason for ID to export not-quite-right png files sometimes...
Have you rasterised any of the text frame?
Have you tried on multiple readers and having issue on all of them?
Sharing your InDesign doc would be of great help to narrow down the scenario.
I have not rasterized the text frame. I simply created the text box, formatted it with border and fill, and typed in the text. The epub is here: Dropbox - Biology Through the Eyes of Food.epub. It's a big file, I'm afraid. Pages 44, 45, and 47 illustrate the problem; page 48 illustrates my fix for integrating html5 animations created in Flash. I edited some of the png files for text boxes elsewhere in the book, to make sure they shared the problem of incorrect dimensions; I have not verified that the phenomenon holds true for these, but I bet it does.
The epub looks exactly the same in Digital Editions.
OK... I have more information.
The latest iteration of FXL epub export creates the text boxes as data:png/base64.... which creates the png image on the fly. So far, so good. But it doesn't always give the png image the same dimensions as the original text box in ID. It is often off by a pixel or two, especially with boxes that have very different horizontal and vertical dimensions (ie thin rectangles rather than squares). Figure legends for images often are much wider than tall, so this is a problem.
After unzipping the epub and attempting to adjust the dimensions assigned in the css files, I find that Firefox reads/presents them slightly differently than does iBooks. Firefox is more forgiving, such that "corrected" borders (as viewed in Firefox) are still missing a border when viewed in iBooks.
In attempting to correct the dimensions using Firefox as the xhtml reader, I often find that adjusting the horizontal dimension to make the right-hand border appear ... has the effect of making the bottom border disappear, and vice versa. I can make it look OK in Firefox by setting the dimensions with fractions of a pixel, but iBooks' stricter criteria still produce a missing border.
This problem is somewhat vexing, we might say, in a textbook with 600+ pages and probably more text boxes in the figure legends for the MSOs.
I have uploaded an indd file and the epub file derived from it to Dropbox, at Dropbox - text box test.indd
and Dropbox - text box test.epub. Here, I created various-sized text boxes, some of which render correctly and some of which do not.
It gets worse. I have also uploaded to Dropbox (Dropbox - glycogen fig.epub and Dropbox - glycogen fig corrected.epub ) an epub file that contains only a single figure from my book. I put the same figure onto 2 pages, differing only in the height of the text box. Being a very short document, ID chose to load the png files for the text boxes as png files, not as data/png:base64 instructions. Therefore, I was able to look at the pngs directly. Their dimensions differed slightly from the original dimensions of the text boxes in the ID file. The result is that the right-hand border fails to show up.
I unzipped and edited the file to create the "corrected" epub. In the figure legend on one of the pages, I adjusted the xhtml to specify that the dimensions of the text box match the dimensions of the png file exactly. In the other, I adjusted the dimensions of the png image itself, to match the original dimensions I had entered into ID. Only the second method created a text box with all of its borders. The first method failed to solve the problem.
I then went back to the "text box test" epub and checked the actual dimensions of the png images (also not loaded as data/png:base64 instructions). I entered those dimensions (in blue) into the png files. Therefore, when you look at the epub, you will see the dimensions I entered into ID, and the dimensions that ID created for the png images.
Of course, I don't know what methodology ID uses to create the png files (or why it should create an image, rather than instruct the epub reader to build a box with a border and a fill). Whatever it is, this methodology seems to be a little off. It's "manageable" for a short document, but not for a long one that shortens the processing time by encoding the png file in base 64. That's not easily edited in Illustrator.