full "page" images with text reflow

[PilcrowandStanza]

Hi all!
New here. Long time book production person, recently turned freelance book designer. while I'm an expert on the print size, ebooks are still a hazy mystery.

I do all my typesetting for print in Indesign, and have had ok luck exporting to epub so far, but have run into a problem:

How can I get text to reflow "around" a full page image? There are some images in this book I can treat as blocks, but most are meant to be on a facing page. Is it a sizing issue? A coding issue?

If anyone has advice on the InDesign end, or a coding tip for editing it in Sigil, that would be wonderful.

Thanks!!
Peggy
Pilcrow&Stanza / book design and production

[Quoth]

Indesign is for paper (PDF) and kludged for ebooks. At best you can use it for fixed layout ebooks (which are a horrible imitation of PDF).

There is no "facing page" concept on real ebooks. While text can flow around an image, it's best that it doesn't for widest compatibility.

All you need is properly styled Word or LO Writer and Sigil or Calibre. It's not "typesetting" as in PDF for paper. Perfectly replicating paper is a fail. Real ebooks are a subset of web pages, but paginated, as a web page would be on a printer preview.

The ebook page is what ever size and resolution the users ereader or app has.
The user expects to vary margins, line-height (so don't set it ever) and font size, and even font-face.

We actually do the epub first, via LO Writer, proof epub and when it's finalised make a copy of the LO Writer doc and add page styles, headers, footers, page numbers, book style formatting etc and output as a PDF for paper.

The source doc for an epub has only one page style, small margins, no headers, footers or page numbers. No white space entered. Everything is paragraph styles which become mapped 1:1 to CSS if you convert an docx to epub in calibre.
Sigil allows hand building epub3, mathml etc.

Indesign is hampering you. Like trying to do calligraphy with a sewing machine.

[Turtle91]

Welcome to MR!

If you want an image to take up the “full screen” then there wouldn’t be any room for the text to flow around. In that case you could insert an image wrapped in svg tags on its own html page. The text would end before the image and pickup right after.

If, instead, you want it to just take up the full width, with text above/below, then you could do something along the lines of:

div.image {margin:2em 0; width:100%}
img {width:100%}

<p>Some text paragraph.</p>
<div class="image"><img alt="" src="yourimage.jpg"/></div>
<p>Some text paragraph.</p>

If you want an image to take up less than the full width of the screen then you would need to incorporate the "float" into your div:

div.image {margin:2em 0; width:75%; float:left}
img {width:100%}

<p>Some text paragraph.</p>
<div class="image"><img alt="" src="yourimage.jpg"/></div>
<p>Some text paragraph.</p>

[jhowell]

I believe that the question is actually about having a full page image with the the text flowing around it so that the previous page contains a full page of text.

See the thread Full-page image "floating" for responsive pagination.

[Quoth]

Originally Posted by jhowell

I believe that the question is actually about having a full page image with the the text flowing around it so that the previous page contains a full page of text.

See the thread Full-page image "floating" for responsive pagination.

Yes, I gathered that. But the simple reliable and works everywhere solution is to have the image as a paragraph where you want it in the sequential paragraphs. You don't know what size a page is, but you can make an image approximately fit the screen with css
height: auto;
width: 95%;
( or vice versa)
and the enclosing p tags are centred with 0 left & right but desired top and bottom margin. Easy & compatible. Things that are at the start of a new file need a padding-top as many platforms ignore margin-top for the first item in a file.

A "Full page" image and text flowing round it is a nonsense in an ebook. Though you can have float, it fails on many platforms, so we never have any "float" in any CSS. No drop caps, image or text based. Ebooks use CSS and HTML, but are not web pages or web sites.

Forget Desktop Publishing, which is what InDesign is derived from. Or Web site design.

[RbnJrg]

Originally Posted by Quoth

A "Full page" image and text flowing round it is a nonsense in an ebook.

Why? I don't understand why. In my post:

https://www.mobileread.com/forums/sh...3&postcount=14

you can see examples with a full page image, with a full page text before and after the image. Of course, that only can be obtained under epub3 but I can't see the reason about why that is a nonsense in an ebook. With the proper code, no matter the font-size, no matter the font-family, the image always will be at full page, and the text before and after the image, will be also at full page (the only "drawback" is that the image will be able to be displaced half page up or down at most, regarding the text around). A nice effect, not possible with epub2. Fragmentation doesn't exist with epub3; there are none blank spaces unwished.

[RbnJrg]

Originally Posted by Quoth

You don't know what size a page is, but you can make an image approximately fit the screen with css
height: auto;
width: 95%;
( or vice versa)

No, that's not enterely true. What happens with an image whose width is bigger than its height (let's suppose an image of 300px x 100px)?. With your code:

height: auto;
width: 95%;

the image will take a half of the screen at most. If you, for the same size image, instead use:

height: 95%;
width: auto;

you won't be able to see the full width (at most, you'll see half width). And even more, the height of 95% will generate issues, because the image will take 95% of the height of the container and, what is the height of the container? Where is defined such height? If you don't want to worry about the size of a page or container, you have to work with viewport units. Of course, under the epub2 world that can be an issue. But we can't speak as if the world were only epub2; there is code for epub2 and there is code for epub3.

A "Full page" image and text flowing round it is a nonsense in an ebook. Though you can have float, it fails on many platforms...

That statement is gratuitous, with nothing to back it up. And what is freely stated can be freely denied. If we are speaking about epub3, then the layout will be supported for any ereader with proper support for epub3. And I am not going to state something gratuitously, I will do it by citing ereaders with full support for the epub3 protocol. Here you have a list of ereaders that will display properly a full page image:

ADE 4.x (Windows), Thorium (Windows and Linux), Koodo Reader (Windows and Linux), IceCream Ebook Reader (Windows), Foliate (Linux), Readium, Bibi Reader and JSReader (all Sigil plugins on both Windows and on Linux), Calibre Viewer (Windows and Linux), EPUBReader (extension for Chrome and Firefox), ePUB Reader (another extension for Chrome and Firefox), PocketBook (Android), Gitden Reader (Android), Reasily (Android), Aldiko Next (Android), Lithium (Android), OverDrive (Android), Bluefire Reader (Android and IOs), BookFusion (Android).

so we never have any "float" in any CSS. No drop caps, image or text based. Ebooks use CSS and HTML, but are not web pages or web sites.

Before those words you should have added the phrase "according to what I think". What you wrote is what it seems to you, but it is not the absolute truth. You have a very old idea about what a modern ereader can offer (Readers have evolved a lot since ADE 2.x). In fact, I demonstrated in my post that it is not only possible to obtain what the OP asked, but that the results are desirable.

[Quoth]

Originally Posted by RbnJrg

No, that's not enterely true. What happens with an image whose width is bigger than its height (let's suppose an image of 300px x 100px)?.

Read the post. "Or vice versa".

[RbnJrg]

Originally Posted by Quoth

Read the post. "Or vice versa".

Yes, I read it; you didn't read what I wrote.

Explain how it works the code with a height of 95% (for an image); give us a practical example (post a simple epub -or post the code- to show us how will work an image with "height: 95%" and text before and after that image). I am particularly interested in knowing 95% about "what" will occupy that image (if instead of 95% I will employ 950%, the image will be ten times bigger?) I look forward to seeing that miracle because I will learn something that until now, I thinked that was impossible (to use % for height when the height of the container is not previously defined).

And you didn't explain why is a nonsense, in an ebook, a full page image (or a full page table). Maybe you discovered something and will be very usefull for all of us to know why is a nonsense such kind of images.

[Quoth]

Originally Posted by RbnJrg

(if instead of 95% I will employ 950%, the image will be ten times bigger?) I look forward to seeing that miracle because I will learn something that until now, I thinked that was impossible (to use % for height when the height of the container is not previously defined).

You should examine the real market in% share and not leading edge solutions. People designing web sites with your attitude to bleeding ebook design make sites that only work in a few browsers with recent upgrades.

You are not worth arguing with.

if instead of 95% I will employ 950%, the image will be ten times bigger?

Such a stupid statement.

[PilcrowandStanza]

Originally Posted by jhowell

I believe that the question is actually about having a full page image with the the text flowing around it so that the previous page contains a full page of text.

See the thread Full-page image "floating" for responsive pagination.

YES! This is what I'm trying to do, and seems to have worked for the poster in the other thread.

However, because I'm a coding dummy (my HTML knowledge is 20yrs old), is there a precise block of code I should enter into the Sigil editor and exactly where?

Everything else in the text appears to be working ok. Inline images are also no problem (though will try to float these at the top/bottom of pages as well)

Another general question: is it better to remove images you want to float out of the generated HTML, then add them in when editing the epub with correct coding?

Getting ever closer to my head not exploding. Thanks!

[RbnJrg]

Let's go by parts.

First at all, you said the following:

A "Full page" image and text flowing round it is a nonsense in an ebook.

Three times I asked you why is a nonsense, why is a nonsense a full page image or a full page table in an ebook. You was not able to answer that question. Why? Because is not a nonsense; your statement was an error.

Also you wrote the following:

You don't know what size a page is, but you can make an image approximately fit the screen with css
height: auto;
width: 95%;
( or vice versa)

That's not true. With:

  width: 95%;
  height: auto;

you won't get a full page image if the image has a landscape layout. And the "vice versa" is impossible (it seems you write things that you never bothered to fact-check). For that reason, when I wrote:

if instead of 95% I will employ 950%, the image will be ten times bigger?

was not a stupid statement, by the contrary, was a smart one. Because is exactly the same to use 95%, 950% or 25% or whatever value you want to use because PERCENTAGE UNITS IN HEIGHT DOESN'T WORK! For "height" you need to use "vh", "vmax", "px", "em", etc., etc., but not %. So, your "vice versa" doesn't work. To use %, you need to previously set the height of the container and, how do you set such container height? What units do you use to set the container height? You can't use again "%" (I doubt those questions have ever crossed your mind; of course, I know how to deal with such situations).

Be sincere. You build your epubs from Word and turn it into an ebook with Calibre. Because of that, your knowledge of CSS and HTML is very limited, you barely know the basics. That is not a sin, since no one is born knowing. What is a sin is advising someone who is looking for help, like the OP, from ignorance, pretending to be an expert and specialist. To you, the design of an epub must be similar to what can be achieved with a typewriter.

Today's epub is an epub3 built as follows:

1) First, to employ the best code available for an epub2 (this is the fallback code).

2) Above the previous code, based on @support, the epub3 code is incorporated (I give you a simple example so you can understand it: you want to center something vertically as perfectly as possible. In the epub2 code, you establish a top margin that adjusts, more or less, to the desired position. With the epub3 code, you override the top margin and use "display: flex" and center vertically with the flex-box properties).

3) Add a toc.ncx to the epub so that epub3 can be read by epub2 readers. Of this way, the best of both world will be in the hand of a reader. (Of course, you have to work more; of that way and following with the example, if the ereader has support for epub3, things will be displayed perfectly vertically centered, if not, it will be vertically center more or less well. The same is valid for all the others properties).

In the future, if you want to help someone who comes to MR seeking advice, keep quiet, you'll be doing him/her a big favor.

[Quoth]

Originally Posted by RbnJrg

Be sincere. You build your epubs from Word and turn it into an ebook with Calibre. Because of that, your knowledge of CSS and HTML is very limited, you barely know the basics.

Stupid arrogant assumption.
I did websites, inc server side as a paid job, ever since CSS existed, and stupid websites with static HTML before that. Also many more years real programming: in C, C++, Forth, Modula-2 and Java. Designed and implemented hyperlink systems before HTML existed (though didn't use Apple's Hypercard). Designed and built multimedia systems before ebooks existed.
But ebooks, even epub3 (of which there are broadly 3 kinds) are not websites or even web pages. The specs are a subset, and actual implementations vary from different to a subset.
I've hardly used actual MS Word for over 10 years.
I test on epub apps (4.3" to 10" screen), 5 different brands of epub based eink (4.7″ to 10.3″ screen) and on three kinds of eink Kindle.
Was originally editing HTML and importing it to Mobipocket Creator, though mobi was obsolete when it came out.

I do make mistakes.

ThingA: auto
ThingB: some value

You seem to think vice versa is
ThingB: some value
ThingA: auto

It's not. Vice versa would be
ThingA: some value
ThingB: auto


KISS principle. Clever stuff breaks. You are a fanatic that would result in ebooks only working on a small percentage of actual retail users platforms. Are you a Moderator that you have the right to shut me up and close debate?

[PilcrowandStanza]

guys! I love that there's a debate over ebook structure, but can we get to the answers on what actually works? Thanks!

[DNSB]

The answer is that there is no one answer that will work on all ereading devices and applications. What you can do is to try to have it work on as many as possible which generally results in the use of simple CSS which will not allow your text reflow.