Universal Solution for Centering Text Under Image

[exaltedwombat]

If you're making eBooks that need to be portable between various EPUB and Kindle devices, you need to develop a throughly non-anal mindset! You can be fairly confident the words will come out in the right order. Your paragraphs may be indented, they may be separated by white space, but they will be recognisible. Headings will be distinguishable from body text. But that's about it - and I'm not joking! There are so many variables, and so many ways the customer can mess things up with settings and preferences.

You can choose a picture format that you think guarantees the caption will be on the same page. But then a customer will decide to always hold his device in landscape format... The sure way to make a caption stick with its picture is to incorporate it in the graphic. But then the text size will be unpredictable, which can be quite annoying.

I recently moved across to the dark side and designed a book for print. It was quite a wrench to adjust to being in charge of everything - typeface, line ends, spacing, headers, page numbers - and they would show the same for all readers! :-)

[Turtle91]

Originally Posted by Trane

@ Turtle ... I couldn't stand it and re-did a new epub for testing... and you were exactly right, I forgot to link the CSS. (That would explain why none of the methods in the links worked!)

Looked beautiful in Kindle Previewer for all Kindles they model. And in Sigil. (Am assuming this will work in epub too?)

... in your notes you said to set the CSS width to the actual pixel size of the pic. (Which I did for the test.) How does this spec work exactly? Like if that width in the CSS doesn't match the actual pixels of an image, what's the consequence?

No worries, it's happened to all of us!

Setting the width of the image to 100% and the max-width to the pixel size of the image simply means that it will scale (completely fill) to the size of the parent element (the <div> in this case) but it won't get any larger than the actual image...ie. it won't get over stretched to the point it looks blurry/ugly.

this is not a concern if you have super hi-res images (larger than current displays), but it can be an issue if you are working with small originals.

[Trane]

Originally Posted by JSWolf

If the program/device handles KFX and there is a KFX version available, you'll get KFX. If the program/device handles KF8 and there is a KF8 version available, you'll get KF8. If the device doesn't handle KF8, you'll get Mobi. If you have a device registered to your account and you USB download the eBook, you get KF8 if there is such otherwise you get Mobi.

Holy cow. Thank you SO MUCH for explaining this. I plan on getting a 10-block of ISBNs and will need one for every different format. But if Amazon only allows uploading the ebook in mobi when I publish, how do I make the other formats available to Amzn? (sorry for being so dense!)

EDIT: Found this (third post down) which explains (what you already know)... that when KindleGen creates a mobi from an epub it actually creates two books, one in Mobi7 for older Kindles, and one in KF8 for newer, both zipped into the single resulting mobi. So I guess the files are generated automatically by Amazon. [edit out ISBN question as it looks like all Kindle formats can use the same ISBN from what I read]

[Trane]

Originally Posted by Turtle91

No worries, it's happened to all of us!

Setting the width of the image to 100% and the max-width to the pixel size of the image simply means that it will scale (completely fill) to the size of the parent element (the <div> in this case) but it won't get any larger than the actual image...ie. it won't get over stretched to the point it looks blurry/ugly.

this is not a concern if you have super hi-res images (larger than current displays), but it can be an issue if you are working with small originals.

Thanks so much Turtle. You explained that beautifully.

[Trane]

Originally Posted by exaltedwombat

If you're making eBooks that need to be portable between various EPUB and Kindle devices, you need to develop a throughly non-anal mindset! You can be fairly confident the words will come out in the right order. Your paragraphs may be indented, they may be separated by white space, but they will be recognisible. Headings will be distinguishable from body text. But that's about it - and I'm not joking! There are so many variables, and so many ways the customer can mess things up with settings and preferences.

You can choose a picture format that you think guarantees the caption will be on the same page. But then a customer will decide to always hold his device in landscape format... The sure way to make a caption stick with its picture is to incorporate it in the graphic. But then the text size will be unpredictable, which can be quite annoying.

I recently moved across to the dark side and designed a book for print. It was quite a wrench to adjust to being in charge of everything - typeface, line ends, spacing, headers, page numbers - and they would show the same for all readers! :-)

Thanks wombat. I actually considered submitting the manuscript to a major print publisher instead. I'm still half-considering it. But I hear what you're saying... have to just do a good job and realize the limits of the e-book industry at this point (i.e. the nonconformity compounded by the extraneous variables of all the devices). I'm starting to get it...

[Tex2002ans]

Originally Posted by Trane

One thing that mitigates all the points (AFAIC anyway) is that this is a how-to book, so if someone wants red or blue text and a different typeface, and the captions are in black arial, that's not a deal breaker to me, and I can't see it being one to the reader since this is a utility book.

Other things to keep in mind about Accessibility (and why ebooks are awesome). As an example, many readers who are Dyslexic and may read with a specialized dyslexic font like OpenDyslexic:

https://opendyslexic.org/

Someone like that may have a very hard time reading your captions if they were in the JPG.

Just because YOU have no problems with the "Black Arial 12pt", doesn't mean others would have zero problems.

Ebooks are great because of the user preferences... and they can set it the way that perfectly works for them! Our job as the ebook makers is to create the clean text, and then step out of the way and let them read how they want.

Originally Posted by Trane

I also won't be updating any pics in the future.

That's what they all say... until next month you want to change the caption.

(That actually happened after I strongly advised against it.) :P

They wanted it redone, I said "I told you so", and they paid me a second time to do the new captions (new caption images had "Figure #:" changed to bold)... then about a year later, guess what? They wanted the captions in HTML. Luckily I left the proper HTML solution as an HTML comment... so I just swapped in the original uncaptioned images + a Search/Replace that took about a second.

So I got paid 3 times as much for something that should have been done the first time! :P

Originally Posted by Trane

But I hear what you're saying and it's always best to err on the side of caution, and I know enough to know I don't know anything, and you've been through this and are cautioning me, and I am listening. I will re-do Turtle's suggestion in A.M. and look more closely at your code too to see if my pea brain can manage to figure it out (looked like a lot of captions?) and see if I can get up on this horse.

Yeah, my example code is pretty much what I settled on. My solution has to work across hundreds of books, not just one. I can then use the same exact code whether there is zero/one/three captions + multiple images + sentences/paragraphs of explanation! :P

Most of the time you will probably just have a single caption, so you could go with something very simplified like this:

Spoiler:

<div class="figure">
	<div class="wholeimage"><img alt="Figure 1: Trees" src="../Images/Figure1.jpg"/></div>
	
	<p class="caption">Figure 1: Trees</p>
</div>

That initial example was out of one of the "harder" books. :P

Originally Posted by Trane

Thanks wombat. I actually considered submitting the manuscript to a major print publisher instead. I'm still half-considering it.

Hey I thought you said you would never redo those images!

Guess what the Publisher would do... they would want to style captions just like all their other books, and then they will pull their hair out and charge you MUCH MUCH more for submitting hardcoded captions! And they would look like complete crap because Print is much higher DPI (300+ DPI) than Web (~72 DPI). :P

Originally Posted by Trane

But I hear what you're saying... have to just do a good job and realize the limits of the e-book industry at this point (i.e. the nonconformity compounded by the extraneous variables of all the devices). I'm starting to get it...

And that's the thing, sort of like with this page-break-avoid, we follow the standards and hope devices in the future get better (and they will). Let's say 10 years down the line, Reader XYZ will avoid breaking the page and fit the captions right below the image... and you will be glad you had the foresight to make it work. Long-term thinking is the best thinking!

Originally Posted by exaltedwombat

I recently moved across to the dark side and designed a book for print. It was quite a wrench to adjust to being in charge of everything - typeface, line ends, spacing, headers, page numbers - and they would show the same for all readers! :-)

Yeah, designing a book for print opened my eyes to a massive amount of little niggles that I never noticed before. Makes you see where ebook renderers still need a ton of advancements (like in Justification/Hyphenation/Microtypography).

[Trane]

Originally Posted by Tex2002ans

Yeah, my example code is pretty much what I settled on. My solution has to work across hundreds of books, not just one. I can then use the same exact code whether there is zero/one/three captions + multiple images + sentences/paragraphs of explanation! :P

Most of the time you will probably just have a single caption, so you could go with something very simplified [...] That initial example was out of one of the "harder" books. :P

Yes, very impressive!

Hey I thought you said you would never redo those images!

I wouldn't. That was one of the reasons I was considering print... to not have to mess with the images [by placing text in them]. I was just having a bad afternoon... I am very over this project and want it behind me, but am not the type to 'mess through the end' b/c of that. I was able to use Find/Replace to replace all the figcaption code with Turtle's code (I understood it easier ) and all the pics look great.

And that's the thing, sort of like with this page-break-avoid, we follow the standards and hope devices in the future get better (and they will). Let's say 10 years down the line, Reader XYZ will avoid breaking the page and fit the captions right below the image... and you will be glad you had the foresight to make it work. Long-term thinking is the best thinking!

Good point and I hope it's so, but it's at least as likely the current code methods for centering text under images will become legacy b/c there will be some new standard in 10yrs and the old code won't be honored anymore. But regardless, it's still better than embedding the text in the image. I was only resorting to that b/c nothing else was working for mobi (my project was coded with the figcaption method). Of course it REALLY helps to link the CSS to the Sigil file! If I had tested the methods in my working project I would have found they worked sooner. But I created a test epub and boo-boo'd.

Yeah, designing a book for print opened my eyes to a massive amount of little niggles that I never noticed before. Makes you see where ebook renderers still need a ton of advancements (like in Justification/Hyphenation/Microtypography).

Yeah, it always takes hardware time to catch up and become standardized, but I was surprised most by the fact there isn't existing, universal, standard e-book code for simple, basic things... like the subject of this thread and also floating images... which from what I understand mobi doesn't do. Hardware cannot become standardized until the code does. And Amazon threw a wrench in that cog in the very beginning by insisting on their own proprietary format, but they could still make it compatible with standard epub code... however, obviously they don't. (Reminds me of the browser wars of the late 90s.) Everybody wants to rule the world.. cue Tears For Fears!

[GrannyGrump]

I just had to chime in with one subversive thought ---- where is it graven in stone that captions MUST be centered? I have seen many print books, and used myself in epubs, captions that were left-aligned, right-aligned, and right-aligned with a left-hand margin of 50%.

Don't feel like you have to hold your output to a single option.

[Trane]

Thanks Granny. As it happens it sounds like it's a crapshoot where the text will land no matter what you do, but for the moment Turtle's code has it all working as far as I can tell.

I'm now wrestling with the next issue with images... sizing. One nightmare after the next. I can't tell from the myriad of opinions and advice which pixel width is best. And Amazon says to go by height instead, making them 1200-something px high. Others say make them 600 or 800px wide. Then some say PPI/DPI doesn't matter, and Amazon says make them 300DPI.

And clearly no matter which one chooses, they will not display well in some devices. Of course choosing gigantic hi-res images is safest, but also costs a bundle in downloading against the royalty when it's a 74k book with 100 images, like mine.

I have defaulted to redoing all (have the originals as PSDs) as 300 PPI and 600px wide. I got through half of them last night then thought I'd better stop in case I found out today another size was better. Like maybe 800px.

Input?

[Tex2002ans]

Originally Posted by Trane

Thanks Granny. As it happens it sounds like it's a crapshoot where the text will land no matter what you do, but for the moment Turtle's code has it all working as far as I can tell.

I haven't personally thoroughly tested Turtle's code example, but here are some things to keep in mind when testing any sort of Image/Caption stuff:

• Stretch/shrink the window size.
  
  • Sometimes images don't scale properly when the device is smaller than the image size. (Heavily distorted or goes off the page)
• Make the font size larger/smaller.
  
  • Most of the time I avoid setting left/right margins as ##em because the larger the font, the less screen real estate you give yourself.
    
  • Depending on code, sometimes spacing between Image/Caption they can sometimes grow too large.
• Test devices in Landscape, not just Portrait.
  
  • Quite often very skinny/tall images will stretch to the width of the screen, but go flying off the bottom of the screen. This is partially why we promote SVG wrappers in certain cases, but old MOBI throws a wrench in that (if you are designing purely for EPUB that could work, or if you don't mind doing a separate EPUB with more MOBI-specific work).
• Test with images that are Tall/Skinny, and Short/Fat.
  
  • You may need to come up with two different image CSS. One for "tall" images, and one for "fat" images.
• Test with longer captions, not just short ones.
  
  • Short: "Mona Lisa"
    
  • Longer: "Example 20: Mona Lisa by Leonardo da Vinci. Painted in 1503. 77 cm × 53 cm."
    
  • Sometimes it centers + looks ok when it is Short, but when the Longer text flows to the next line, things look horrendous.
• Test with much lower/higher resolution images.
  
  • Most of the time you don't have the luck of a book of same-sized images (not all uniform resolution). Sometimes you have a little 400x600 JPG and you may have access to a 1200x1600 PNG, or any sizes in between. Trying to force everything down to 600px width or trying to raise your 600px image larger might cause issues.

A lot of this then depends on your specific images... which is why I didn't post any sort of image-specific code in my examples.

Originally Posted by Trane

I'm now wrestling with the next issue with images... sizing. One nightmare after the next.

[...]

I have defaulted to redoing all (have the originals as PSDs) as 300 PPI and 600px wide.

I got through half of them last night then thought I'd better stop in case I found out today another size was better. Like maybe 800px.

What sorts of images are we talking about. These are purely vector images? Can you post examples?

If they are Text-based (Formulas or image of a Table), Charts/Graphs, line-drawings, [...] those would be much better served as PNG over JPG. PNGs can then be heavily compressed with zero loss.

For example, I posted a vector chart I worked on that was >130KB JPG, but 99.8KB PNG -> 44.5KB PNG (Indexed):

https://www.mobileread.com/forums/sh...45#post2499645

Does this book also have photographic images? What resolution is the source photos?

Originally Posted by GrannyGrump

I just had to chime in with one subversive thought ---- where is it graven in stone that captions MUST be centered? I have seen many print books, and used myself in epubs, captions that were left-aligned, right-aligned, and right-aligned with a left-hand margin of 50%.

I recently saw a physical book that had captions vertical along the Left/Right edge of the image. It also had Headers/Footers done similarly (vertical along the Outer edge instead of at the Top/Bottom of each page).

I thought it looked pretty cool, and seemed like a good way to design the page to create a shorter/wider book.

[Trane]

Thank you for all of those excellent tips! There was also a lot of good information in your other post you linked to. Very helpful.

About half the images are photos (jpgs) from a variety of sources, so there is no one resolution, but I purposely sought out the highest quality images I could find for the subject needed. Using PS to change PPI to 300... most were 240PPI so not a big jump. Also making them a uniform 600px wide. And again, most were close to that. Then Save for Web to compress/strip metadata.

The other half include transparency (just about all created in PS), so made those pngs. There is a nice little (free) plugin for Photoshop called SuperPNG. It does a great job of compressing/removing metadata.

Having tried a few compression/meta-stripping programs prior, I found the two methods above to give the best results, in my case, for my images.

BTW, Amazon says not to compress the cover. Mine is the Amazon-recommended 1600x2560 300PPI (EDIT: I saw they actually say 72DPI is fine, and slight compression too).

[Trane]

Just read in KDP guide that Amazon only supports GIF and JPG, and all PNGs are converted to JPG in the upload process... which means those images will lose their transparent background, and it will become WHITE. So the only way to preserve transparency is to use GIF.... so all the time spent converting the PSDs over again into PNG was wasted (originally made GIFs then read PNGs are superior), and now have to create all new GIFs again and then replace them in Sigil... Again... (Yes, I saved the original GIFs but as I made the PNGs I added effects in PSD to each image that I want in the GIFs, so...)

If they are only going to support one format that includes transparency, why the old, outdated, one? The PNGs created from the PSDs were superior to the GIFs and also compressed to be slightly smaller, still looking better.

Meanwhile, GIF will continue to include transparency once uploaded to Amzn, right? I mean, internal images in eBooks can include transparency, correct?

EDIT: OK, it seems Amazon changed things up at the end of 2015 and since then all images are converted to JPEG XR, including GIFs. When they started doing this GIFs lost their transparency too, even though this newer JPEG XR format supports transparency (unlike normal JPEG). Then apparently Amazon claimed they were going to fix that. (source) So does anyone know if they have? Are currently uploaded GIFs converted to JPEG XR with transparency intact?

[Tex2002ans]

Originally Posted by Trane

About half the images are photos (jpgs) from a variety of sources, so there is no one resolution, but I purposely sought out the highest quality images I could find for the subject needed. Using PS to change PPI to 300... most were 240PPI so not a big jump. Also making them a uniform 600px wide. And again, most were close to that. Then Save for Web to compress/strip metadata.

What's the average size of those JPGs? Maybe the quality can be tweaked slightly lower, or color can be changed from 4:4:4 -> 4:2:2. Or if they are grayscale you could save as Grayscale JPG. All depends on the images.

Originally Posted by Trane

Just read in KDP guide that Amazon only supports GIFF and JPG, and all PNGs are converted to JPG in the upload process... which means those images will lose their transparent background, and it will become WHITE.

This is Amazon's Kindle Publishing Guidelines. This is what you should trust:

https://kindlegen.s3.amazonaws.com/A...Guidelines.pdf

The KDP section of the site you mentioned is more for non-technical Word users. It also has a lot of wrong/misleading/dumbed-down information in it.

There USED TO BE a very old Kindlegen bug that converted PNG Transparency -> black background. Then also used to be a problem where it was converting Transparent PNG -> JPG.

Those two bugs were fixed years ago though.

There was also another PNG Transparency bug in KindleGen a few years ago:

https://www.mobileread.com/forums/sh...85#post2635085

but I haven't retested that in a very long time. It only happened with only a very specific method of compression and turned the entire image black.

Personally, I would export the PNGs with transparency, then run ImageMagick to mass convert those -> white background. Non-Transparent PNGs allow you to get much smaller filesize (if this filesize is such a concern). And doing it that way allows you to easily drag/drop the Transparent PNGs in the future.

Originally Posted by Trane

So the only way to preserve transparency is to use GIFF.... so all the time spent converting the PSDs over again into PNG was wasted (originally made GIFFs then read PNGs are superior), and now have to create all new GIFFs again and then replace them in Sigil... Again... (Yes, I saved the original GIFFs but as I made the PNGs I added effects in PSD to each image that I want in the GIFFs, so...)

GIFs are ancient. PNG is superior in every single way. I wrote a post about this in 2013:

https://www.mobileread.com/forums/sh...54#post2632254

and I also wrote another post why PNG is superior to JPG when dealing with "artificial" images:

https://www.mobileread.com/forums/sh...10#post3029910

Originally Posted by Trane

The other half include transparency (just about all created in PS), so made those pngs. There is a nice little (free) plugin for Photoshop called SuperPNG. It does a great job of compressing/removing metadata.

Having tried a few compression/meta-stripping programs prior, I found the two methods above to give the best results, in my case, for my images.

Personally I am still a fan of ScriptPNG (about a year ago he merged his ScriptJPG+ScriptPNG into another program called pingo):

https://css-ig.net/pingo

Others use OptiPNG or TruePNG or whatever other tools. I believe there was another topic where everyone discussed their favorite compression methods (I swear it was one posted by GrannyGrump, but I couldn't find it in a quick search).

Pingo is just easy drag/drop and typically gets you the highest compression without needing to tweak any variables.

[Trane]

Thanks for the updated PDF guidelines. I will read the PDF to see if it addresses retaining transparency.

My issue isn't with compressing, JPG or PNG. I already did that and they came out wonderful.

My issue is I want to retain transparency. A white bg is not acceptable.

[GrannyGrump]

Originally Posted by Tex2002ans

and I also wrote another post why PNG is superior to JPG when dealing with "artificial" images:
<snip>........
I believe there was another topic where everyone discussed their favorite compression methods

PNG is indeed good for "artificial" images, but just to clarify --- 8-bit (256-colors) is fine for "flat" colors or black & white, but is NOT sufficient for anything with gradients --- gradients will usually show banding, or "posterizing". For those, you must use 24-bit (16-million colors), and they will look beautiful, but they will be enormously larger than jpeg.

Tex, I think the topic you are remembering is this one:
https://www.mobileread.com/forums/sh...d.php?t=225518
I tripped over it recently, after it had completely fallen out of my memory I have been re-reading it and starting to use some forgotten tips from that thread, even if it is from 4 years back. I still always use Jellby's tip to down-size in several steps --- it works wonderfully to reduce the jaggies!