reliable picture layout (anchoring to paragraph) on Kindle-compatible formats

[AoiHana]

Hi.
I'm rather new to ebook edition... and discovered it was hell on Earth just to have a simple picture layout on Kindles...
I want pictures on the left, with a paragraph on the right, like this:
Were I enlarge characters, the paragraph would reflow seemlessly while the picture stays fixed. I did it, I know it's possible, the problem is the result is not reproductible or consistent from picture to picture, like, not at all.
I'm on Libreoffice writer. I think it worked while anchoring was "on paragraph", and I converted the whole to... I don't remember. mobi or azw or azw3. Shit .
How do you lot do ? If kindle can manage to do it once, there should a reliable way, a snippet that would do the job !

Thanks !

[Quoth]

It's not reproducible on different ereaders or formats either.

So I Anchor as Character in LibreOffice Writer and make each image be a separate paragraph that has a centre style.

There isn't even one sort of Kindle.

It's possible. I've even done what I think is the greatest evil, drop caps as images with the text as a property. IMO they look pretty on paper, but slow your reading.

Having Float Left or Float Right (which is really what anchor to paragraph implies) is possible. But the results and text flow varies with platform, text size and format too much.

You can't do it purely in LO Writer. You need to edit the ebook CSS.

[Hitch]

Originally Posted by AoiHana

Hi.
I'm rather new to ebook edition... and discovered it was hell on Earth just to have a simple picture layout on Kindles...
I want pictures on the left, with a paragraph on the right, like this:
Were I enlarge characters, the paragraph would reflow seemlessly while the picture stays fixed. I did it, I know it's possible, the problem is the result is not reproductible or consistent from picture to picture, like, not at all.
I'm on Libreoffice writer. I think it worked while anchoring was "on paragraph", and I converted the whole to... I don't remember. mobi or azw or azw3. Shit .
How do you lot do ? If kindle can manage to do it once, there should a reliable way, a snippet that would do the job !

Thanks !

I can promise you that it is, flatly, not reliably reproducible on Kindles or ePUB readers and speaking bluntly, (if you are not doing this only for your own reading pleasure) it's a highly problematic idea, usability- and readability-wise, and I say this as someone that's not only done floated images, but, shame on me, sidebars, successfully (so to speak) in MOBI/Kindle formats.

For one thing, in eBooks, your floated images are anchored to a specific paragraph and in MOBI, generally, they anchor to a specific "point" in the paragraph, typically the top of the paragraph. No matter how clever you are, you can't make the "flow" of the text around/adjacent to that paragraph smooth, "seamless." It won't be. At some point, if the end user enlarges the font (or reduces it!), you will end up with either, the paragraph hanging in space, with the image tagged to the top of it, sitting there like the "eye" of a upper-case P, or with reduced font, you'll have the text all scrunched up to the left/right of the paragraph, with a big gap below it to the following paragraph. It's just not like print.

I mean...on a smartphone or smaller reader, you get someone who reads at font size 6-7 and they're going to have a line with 2-3 words on it, max, adjacent to the image. That's no bueno.

And lastly, you cannot realistically get that to work from a word processor, whether that's Word or OO or LO or AWP or Bob's Big Word Processor. If you can work in HTML, you can do this, if you really wish.

One option--and I'm loath to mention it--is that you COULD do this in tables, but you have the same problem with the cells in their respective rows (and if you are planning to publish to Amazon, Enhanced Typesetting can get very, very cranky around the quantity of tables).

But that does not eliminate or ameliorate the reality of how problematic it is, for publishing, to try to create floated image content, with lines of text over which you have no control, in terms of font size. But that part is just my humble opinion.

Hitch

[AoiHana]

For sure I have only two kindle, maybe the others (non e-ink ?) behave differently ?

Okay, I'm convinced, I can feel you two's bitter resentment just fine !
I could try editing CSS, but you're saying even that won't be reliable ? I do not intend for people to read it on phone, that would need at least a Kindle Basic's screen size. If I do get this requirement, and learn some bit of css, would I get something okay-ish ?

[AoiHana]

But if you say "no", I'll keep with character anchoring... sucks big, why the hell can't they make a better format ! It's not complicated to program it this way "if big enough layout is like this, otherwise put text and picture on separate pages" !
ps: seems like the message didn't pass through... I was asking, if I did go the CSS route, considering I target only at least Kindle Basic's screen size, would I get something remotely reliable ?

[pdurrant]

One message got caught in auto-moderation, now approved. I fixed the image you included in the first post.

None of the current ebook formats work well when the layout (e.g. placement of images) needs to change depending on the page size and font size.

Back in the day, TeX/LaTeX worked well for this, but it was designed for this, and assumed that authors didn't mind too much where the images were placed.

You can probably get something that works OK, most of the time. But it'll be a bit of a slog, and there will always be some situations where it looks bad.

[Hitch]

Originally Posted by AoiHana

For sure I have only two kindle, maybe the others (non e-ink ?) behave differently ?

Different Kindles work differently, period and there are still Kindles in existence that can't display any kind of more-advanced formatting.

Okay, I'm convinced, I can feel you two's bitter resentment just fine !
I could try editing CSS, but you're saying even that won't be reliable ? I do not intend for people to read it on phone, that would need at least a Kindle Basic's screen size. If I do get this requirement, and learn some bit of css, would I get something okay-ish ?

It's not bitter resentment. It's the voices of experience. Between us, me and Quoth, we've made many thousands of eBooks. I mean, you say, for example, that you don't "intend" for people to read it on a phone, but you don't control that, so you can't simply ignore it and not address how those buyers will see the eBook.

Originally Posted by AoiHana

But if you say "no", I'll keep with character anchoring... sucks big, why the hell can't they make a better format !

And what would that be? Seriously? What would be 'better'? I mean, look at your image. How could that possibly lay out--a very small paragraph and a large vertically-oriented picture, so it would look "right" and how could you possibly make that work, no matter what font size the user chooses? What exactly is it that you are envisioning, in terms of "fixing" it?

It's not complicated to program it this way "if big enough layout is like this, otherwise put text and picture on separate pages" !

So, you're a programmer? What types of programs or apps or ?, do you write code for? I'm just trying to understand your frame of reference, when you say "it's not complicated," given that even Apple--which has the advantage of a tablet, not a dedicated eReader--doesn't have an eReading software that does that, not like you're thinking of. ??? Or, as far as I know, even Readium, which has the advantage of being browser-based and with the power of desktop computing, doesn't do...?

And, in that eReader, that is trying to execute that if/then--if not "enough room" put on a new "page," what's a page? How does the eReader "know" whether or not there's enough room? What's the calculation for it? Remember, the software itself doesn't really recognize a "page." Behind that screen is a long roll of digital toilet paper, that scrolls, behind the screen. It doesn't really know "pages." (Which is why, when you change font sizes, the entire damn book re-renders, to over-simplify it a bit.)

So, you want devices to have if/then/else, like media queries and you want it to work like a desktop computer, processing-power-wise, AND you expect the eReader companies to still make lightweight-enough devices that people want to use them?

I have numerous devices, including an iPad that I bought for testing, for eBooks, a while back. When I got the iPad, I thought, wow, yes, this is SOOOOO cool. But you know what? By the time I put an otterbox-like cover on it, to protect it, it was too fracking heavy to use as an eReader. I own a variety of Fires and eInks, Nooks, iPads, tablets, a Boox Note2, etc. And my favorite--the one I use, day-in and day-out, for my reading, is my Kindle Oasis. Nothing else even comes close. I can see clearly and it's lightweight enough where if I have a longer reading session--say, 2-3 hours, my wrists don't feel like I've been doing wrist curls with a 5-lb. weight, when I'm done with my novel or whatever.

ps: seems like the message didn't pass through... I was asking, if I did go the CSS route, considering I target only at least Kindle Basic's screen size, would I get something remotely reliable ?

What your screenshot displays is how it works. Alternatively, you could, if you're really unhappy with it, create two-cells tables and slap them in there, but the end result isn't significantly better.

I'm still curious, how you would envision this actually working? I mean, take the image you've posted here. What end result are you thinking would be acceptable to you, layout-wise? Do you have an image of the end result that you want?

Because even as someone who makes her living, doing this, I'm not sure that I really agree that the functionality is "broken." Sure, sometimes I wish I had some if/then/else functionality, mostly around specific devices and yes, some more control over some elements, based on the screen size and resolution would be nice. (Yes, yes, boys and girls, media-queries do exist, around h/w and all that, but they don't always work in the world of MOBI.) But given that this is a fungible, changeable environment, with completely different screensizes, aspect ratios, pixel density and that someone reading can rotate their device or phone to landscape...I mean, really, what do you see as a possible "fix"?

Hitch

[Quoth]

Shorter answer, even if you hand edit CSS, the idea of images with text flowing is doomed. What Wordprocessors call page or paragraph anchors and what a web page calls Float Right or Float Left.
Even on a web page it's unpredictable, I have to put a HTML special break so inappropriate text from a next paragraph heading doesn't end up beside the image if the user uses small text. Possibly <div style="clear: both;"></div>

Having a centred image with paragraph break before and after, optionally with a width setting (never height) will work. A character anchor in Word or LO Writer. If you use a paragraph style to centre that will automatically become CSS.

It's reliable for paper and thus PDFs, which are either for 10" or larger tablets or proofing paper. Because the user can't change the page size, font face/size or anything.