'Floating' illustrations

lindsayw · 08-29-2011, 02:54 AM

I know that this is not really the right place to post an inquiry like this, but I have not been able to find any answers on the xhtml geek sites. As an additional page for a range of books, I am trying to create a list of books, each one with a cover thumbnail and a very short synopsis. It is in xhtml, and the problem is that different eBook Readers use different file formats, and different xhtml parsers, as well, so there is little conformity.
Let’s say the thumbnail image is left-aligned, and both the image and the synopsis text is contained in a <div>... but the text is not quite long enough to extend to the bottom of the image...

A. On the Kindle, which uses an adulterated MOBI format that does not support the css ‘float’ command, the result is that the text starts at the bottom right of the image, causing an ugly white-space to the right of the thumbnail, and essentially appears mostly underneath the image. The next <div>, with its next thumbnail and accompanying text, lines up below that, etc.
B. On a Reader using the ePub format, which DOES support the css ‘float’ command, the result is that the text, not quite long enough to extend to the bottom of the image, causes the <div> to end part-way down the image. The next <div> with the next thumbnail appears, overlapping the first one to the right, and the text is squashed into a reduced area to the right of that. The third thumbnail will appear overlapping the second one, etc.

In the bad old days of plain-vanilla html, you would just add a <br clear=all> after the synopsis text, and the new <div>, with its new thumbnail and text, would line up below the first one. That is absolutely verboten these days! The logical answer is to add a style=”clear: both;” command to the <div> but that does not achieve what the old html tag did, because css “clear” offers control of left, right, or both... but no height control at all.

Has anyone found an answer to this problem?

Jellby · 08-29-2011, 05:56 AM

What is exactly the height control you want and why "clear: both" is not enough?

I'd say something like <div style="clear: both; margin-top: 1em"> (or create a class) might be what you are after.

lindsayw · 08-29-2011, 02:17 PM

The old <br clear=all> command would make a line-break that extended to BELOW any associated objects like images, however big they were (because images did not 'float' – they were aligned left, center or right). With only left and right css controls you cannot specify a vertical 'minimum height' for a block of text to match the height of a picture. I tried making a simple 2-column table with the thumbnails in the left column, text in the right, and that worked fine, but tables in an eBook are bad news, and I want to avoid them if possible. I suppose I could make a separate 1-row table for every thumbnail-&-text combo, so that page breaks would not split cover images from associated synopses, but it's still messy...

HarryT · 08-29-2011, 02:21 PM

Does <br clear=all> not work any more, or is it just one of those "deprecated" things that makes the file fail in a validation tool?

sourcejedi · 08-29-2011, 02:40 PM

<br clear> has been deprecated for 13 years now (i.e. since HTML 4.0), and as such is not part of xhtml 1.0 "strict", xhtml 1.1, EPUB 2.0, HTML5, or EPUB 3.0.

The clear attribute in CSS1 from 15 years ago is intended to replace it. To be fair, the initial CSS implementations were horrible, so the realistic deprecation time-scale is probably closer to a round decade.

Jellby · 08-30-2011, 04:24 AM

Can you show an example where the <br clear="all"/> behaviour cannot be replicated with CSS? As far as I can see, the difference is with CSS you place the clear attribute in the next element, so, let's say you have something like this:

Code:

<div><img src="some floating large image"/>A short text<br clear="all"/></div>
<p>Normal text following.</p>

With CSS you'd do:

Code:

<div><img src="some floating large image"/>A short text</div>
<p style="clear: both">Normal text following.</p>

(or use a class, or the "adjacent" selector...)

lindsayw · 08-31-2011, 07:53 PM

Thanks, Jellby... I DID try using "clear:both" pretty much exactly as you suggested, but the deeper problem is the lack of comformity between 90% of Readers or Reader apps, all using the ePub file format that DOES recognise the "float" command, and Amazon's Kindle, which uses the MOBI format that does NOT recognise "float", but still has a strangle-hold on 90% of the eBook market. It's a dilemma. You don't want to write 2 versions of every page that needs illustrations... that just gets too hard to manage.

The Work-around: In the end I just edited the illustrations to make rows of images (similar to those shown in my signature) no more than about 300 pixels wide – about a half an average "page", then placed the synopses below that. It looks ok in either format, which is the main thing.

Code:

<4-cover image>
Short synopses of 4 novels
<3-cover image>
Short synopses of a trilogy
<2-cover image>
Short synopses of a duology

JSWolf · 08-31-2011, 09:22 PM

Quote:

Originally Posted by lindsayw

The Work-around: In the end I just edited the illustrations to make rows of images (similar to those shown in my signature) no more than about 300 pixels wide – about a half an average "page", then placed the synopses below that. It looks ok in either format, which is the main thing.

Code:

<4-cover image>
Short synopses of 4 novels
<3-cover image>
Short synopses of a trilogy
<2-cover image>
Short synopses of a duology

So what you are saying it you made the ePub not as good as it could be because Mobipocket cannot handle floating images? Please don't do that. Use ePub more to it's abilities and let Mobipocket fall flat where it falls flat. It's reasons like this that publishers don't do things properly in ePub. I've seen lots of places where blockquotes should be used but are not. Places where images should be floated but are not. And why not? Because Mobipocket doesn't do it.

lindsayw · 08-31-2011, 09:55 PM

Quote:

So what you are saying it you made the ePub not as good as it could be because Mobipocket cannot handle floating images? Please don't do that.

Ahem. So what you are saying is that authors should ignore 90% of the market in order to cater for the lucky 10%? Please don't do that.
I found a way to achieve results for all users... not ideal, but perfectly acceptable. Books are products just like any others, and market penetration is paramount.

JSWolf · 08-31-2011, 10:03 PM

Quote:

Originally Posted by lindsayw

Ahem. So what you are saying is that authors should ignore 90% of the market in order to cater for the lucky 10%? Please don't do that.
I found a way to achieve results for all users... not ideal, but perfectly acceptable. Books are products just like any others, and market penetration is paramount.

But you could achieve optimal results for those who want ePub. That would be better. It also sounds like you've reduced the size of the images when you don't need to for the ePub.

ePub is not 10%. ePub has a lot larger market then you think. Sony, B&N, Kobo, Astak, Jetbook, Pandigital, Pocketbook, and others all handle ePub. With all dedicated readers that handle ePub, it's not 10%. And are you taking into account the world beyond the US? If you do, you'll find even more ePub usage. I have no idea the actual numbers. But it is not 90%/10%.

If you were a user that used ePub, would you want the ePub you were reading to be made a well as it can be?

lindsayw · 08-31-2011, 10:33 PM

Quote:

If you were a user that used ePub, would you want the ePub you were reading to be made a well as it can be?

Yes, of course I would, JS, but if I can format my stuff so that the reader can't really tell whether it possibly could be better, but it works for either part of the market, then that's the sensible way to go. I agree, the 90%-10% split is probably a bit wrong, but it is certainly massively in favor of MOBI for the simple reason that Amazon has stuck to its guns for Kindle marketing reasons. In the longer term, who knows? Perhaps they will relent and upgrade the Kindle firmware to allow ePub files because books with illustrations are typically second-rate in MOBI format? That might happen as tablets gain market share over eBook Readers, and users can compare screens.
But, as a novelist, my stuff is 99.9% text.... I don't really care too much!

08-29-2011, 02:54 AM	#1
lindsayw Author from pBook days Posts: 49 Karma: 10782 Join Date: Mar 2011 Location: Australia Device: Kindle-3-Keyboard; 8" Android Tablet	'Floating' illustrations I know that this is not really the right place to post an inquiry like this, but I have not been able to find any answers on the xhtml geek sites. As an additional page for a range of books, I am trying to create a list of books, each one with a cover thumbnail and a very short synopsis. It is in xhtml, and the problem is that different eBook Readers use different file formats, and different xhtml parsers, as well, so there is little conformity. Let’s say the thumbnail image is left-aligned, and both the image and the synopsis text is contained in a <div>... but the text is not quite long enough to extend to the bottom of the image... A. On the Kindle, which uses an adulterated MOBI format that does not support the css ‘float’ command, the result is that the text starts at the bottom right of the image, causing an ugly white-space to the right of the thumbnail, and essentially appears mostly underneath the image. The next <div>, with its next thumbnail and accompanying text, lines up below that, etc. B. On a Reader using the ePub format, which DOES support the css ‘float’ command, the result is that the text, not quite long enough to extend to the bottom of the image, causes the <div> to end part-way down the image. The next <div> with the next thumbnail appears, overlapping the first one to the right, and the text is squashed into a reduced area to the right of that. The third thumbnail will appear overlapping the second one, etc. In the bad old days of plain-vanilla html, you would just add a <br clear=all> after the synopsis text, and the new <div>, with its new thumbnail and text, would line up below the first one. That is absolutely verboten these days! The logical answer is to add a style=”clear: both;” command to the <div> but that does not achieve what the old html tag did, because css “clear” offers control of left, right, or both... but no height control at all. Has anyone found an answer to this problem?

08-29-2011, 02:17 PM	#3
lindsayw Author from pBook days Posts: 49 Karma: 10782 Join Date: Mar 2011 Location: Australia Device: Kindle-3-Keyboard; 8" Android Tablet	The old <br clear=all> command would make a line-break that extended to BELOW any associated objects like images, however big they were (because images did not 'float' – they were aligned left, center or right). With only left and right css controls you cannot specify a vertical 'minimum height' for a block of text to match the height of a picture. I tried making a simple 2-column table with the thumbnails in the left column, text in the right, and that worked fine, but tables in an eBook are bad news, and I want to avoid them if possible. I suppose I could make a separate 1-row table for every thumbnail-&-text combo, so that page breaks would not split cover images from associated synopses, but it's still messy... Last edited by lindsayw; 08-29-2011 at 02:30 PM.

08-30-2011, 04:24 AM	#6
Jellby frumious Bandersnatch Posts: 7,543 Karma: 19001583 Join Date: Jan 2008 Location: Spaniard in Sweden Device: Cybook Orizon, Kobo Aura	Can you show an example where the <br clear="all"/> behaviour cannot be replicated with CSS? As far as I can see, the difference is with CSS you place the clear attribute in the next element, so, let's say you have something like this: Code: <div><img src="some floating large image"/>A short text<br clear="all"/></div> <p>Normal text following.</p> With CSS you'd do: Code: <div><img src="some floating large image"/>A short text</div> <p style="clear: both">Normal text following.</p> (or use a class, or the "adjacent" selector...)

08-31-2011, 07:53 PM	#7
lindsayw Author from pBook days Posts: 49 Karma: 10782 Join Date: Mar 2011 Location: Australia Device: Kindle-3-Keyboard; 8" Android Tablet	Thanks, Jellby... I DID try using "clear:both" pretty much exactly as you suggested, but the deeper problem is the lack of comformity between 90% of Readers or Reader apps, all using the ePub file format that DOES recognise the "float" command, and Amazon's Kindle, which uses the MOBI format that does NOT recognise "float", but still has a strangle-hold on 90% of the eBook market. It's a dilemma. You don't want to write 2 versions of every page that needs illustrations... that just gets too hard to manage. The Work-around: In the end I just edited the illustrations to make rows of images (similar to those shown in my signature) no more than about 300 pixels wide – about a half an average "page", then placed the synopses below that. It looks ok in either format, which is the main thing. Code: <4-cover image> Short synopses of 4 novels <3-cover image> Short synopses of a trilogy <2-cover image> Short synopses of a duology Last edited by lindsayw; 08-31-2011 at 08:18 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Just an idea: floating DRM	tho	General Discussions	18	07-19-2011 03:07 AM
Help with Search - Floating Point Number	nynaevelan	Library Management	16	04-13-2011 06:37 AM
Floating City with pictures!	shousa	Deals and Resources (No Self-Promotion or Affiliate Links)	6	04-01-2008 09:20 AM

08-29-2011, 05:56 AM	#2
Jellby frumious Bandersnatch Posts: 7,543 Karma: 19001583 Join Date: Jan 2008 Location: Spaniard in Sweden Device: Cybook Orizon, Kobo Aura	What is exactly the height control you want and why "clear: both" is not enough? I'd say something like <div style="clear: both; margin-top: 1em"> (or create a class) might be what you are after.

08-29-2011, 02:21 PM	#4
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	Does <br clear=all> not work any more, or is it just one of those "deprecated" things that makes the file fail in a validation tool?

08-29-2011, 02:40 PM	#5
sourcejedi Groupie Posts: 155 Karma: 200000 Join Date: Dec 2009 Location: Britania Device: Android	<br clear> has been deprecated for 13 years now (i.e. since HTML 4.0), and as such is not part of xhtml 1.0 "strict", xhtml 1.1, EPUB 2.0, HTML5, or EPUB 3.0. The clear attribute in CSS1 from 15 years ago is intended to replace it. To be fair, the initial CSS implementations were horrible, so the realistic deprecation time-scale is probably closer to a round decade.

Advert

Advert