No break space and alignment

[Tex2002ans]

Originally Posted by RbnJrg

I don't understand you. Why do you say that

[...]

doesn't work?

Just tested that specific code too...

The spacing looks okay in Sigil, but in ADE the gap still stretches when I make the window bigger/smaller.

And it still line-breaks (Sigil/ADE/PocketBook).

In ADE/PocketBook, the white-space: pre; also causes this:

This is an example of text —  <--- 2 spaces to right-edge
  Lorem ipsum [...] <--- 2 spaces along left-edge too, so line looks "indented"

... so I'm assuming other font-/screen-sizes... things are also going to explode.

[roger64]

Hi

For my first test with Calibre, I only need one space ("pre") instead of four and the vertical alignment seems OK. If I only use it for dialogues, I do not worrry about line-breaks.


it seems to work OK with Sigil, the Calibre viewer and Prince PDF.

It works also nicely with Koreader ePub (Cool Reader engine)

Next book; I'll try another solution from Tex

[RbnJrg]

Originally Posted by Tex2002ans

Just tested that specific code too...

The spacing looks okay in Sigil, but in ADE the gap still stretches when I make the window bigger/smaller.

The spacing will look ok in all render engine based on Webkit. So, in Sigil, Calibre, Kobo, etc., the aproximation will work perfectly.

And it still line-breaks (Sigil/ADE/PocketBook).

The solution is not intended to be applied in a middle of a sentence, just at the beggining.

In ADE/PocketBook, the white-space: pre; also causes this:

This is an example of text —  <--- 2 spaces to right-edge
  Lorem ipsum [...] <--- 2 spaces along left-edge too, so line looks "indented"

... so I'm assuming other font-/screen-sizes... things are also going to explode.

First at all, PocketBook employs two render engines: RMSDK and WebKit. So, if you use WebKit, no problem should be in PocketBook. Besides, this is not a replace for a bullet in an unordered list; just is to denote a dialog.

Finally, THE SOLUTION FOR RMSDK is the following:

<p>—<span class="ps">&nbsp;</span>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
<p>—<span class="ps">&nbsp;</span>Nulla ac tellus nunc. Phasellus imperdiet leo metus, et gravida lacus.</p>
<p>—<span class="ps">&nbsp;</span>Donec metus ligula, elementum at pellentesque pellentesque, suscipit ac nunc. Etiam lobortis, massa ac aliquam auctor, augue nisl sagittis urna, at dapibus tellus erat ullamcorper ligula.</p>

with

p {
  text-align: justify;
}

.ps {
  white-space: pre;
}

That code works in my testing under ADE, Sigil, Calibre, Azardi and Kindle Previewer 2.92. So, with RMSDK and WebKit works! The issue seems to be with Kindle Previewer 3.35; with some fonts the alignment is not produced. Amazon must be using a different render engine with .KFX (because with .kf8 all is ok). Under .KFX, when Amazon is justifying the text, in some way is adding a space between "—" and "<span class="ps">&nbsp;</span>". And still I couldn't find a fix for that case. Also your aproximation has issues with Kindle Previewer 3.35.

[roger64]

Thank you both for your extensive trials.

I'll use this latest Ruben proposal for my next book. It adds to the no-break quality of the "nbsp" the fixed space of the "pre" css command.

Could it be the best of two worlds?

[JSWolf]

roger, why do you want to use such poor code? Just use a left margin with a negative indent and be done with it. That's what works.

[roger64]

Thanks for your advice.

Ruben's code deserves at least one try. Here it is.

[RbnJrg]

Originally Posted by JSWolf

roger, why do you want to use such poor code? Just use a left margin with a negative indent and be done with it. That's what works.

¿Poor code? I see you didn't understand of the nature of the Roger's issue. He is not seeking a replace for a bullet in an unordered list. By the way, I also see that you didn't bother to test your "rich code" either. If you had done it, you would have seen that the alignment varies with different font sizes, and different font names. You can not set an unique margin and one unique text-indent that work with all font sizes and all font family. So that, it is your solution that is really poor (no offense).

[RbnJrg]

Originally Posted by roger64

Thanks for your advice.

Ruben's code deserves at least one try. Here it is.

I saw it, and to me, it looks perfect! (even with the EPUBReader plugin for Chrome).

[roger64]

I did not test it thoroughly but I'll keep it unless proven wrong by some tester.

Again, thanks for your help.

[Tex2002ans]

Originally Posted by RbnJrg

I saw it, and to me, it looks perfect! (even with the EPUBReader plugin for Chrome).

You're not getting stretchiness on ADE when changing the window size?

[RbnJrg]

Originally Posted by Tex2002ans

You're not getting stretchiness on ADE when changing the window size?

In my test with ADE 4.5 I didn't notice anything with

<p>—<span class="ps">&nbsp;</span>Lorem ipsum dolor sit amet, consectet...</p>

------------

p {
  text-align: justify;
}

.ps {
  white-space: pre;
}

The only issue is with Kindle Previewer 3.35 (with Kindle Previewer 2.92 all is fine). Of course, Roger asked for a solution for .epub, and for .epub, the code above works fine everywhere. But there is problems with .KFX (with .kf8 all is ok). Amazon must be using a different render engine with .KFX, because with WebKit my aproximation works; I tested it with Sigil, Calibre, Azardi, KP 2.92, EPUBReader plugin for Chrome and Roger said that also works with Kobo.

[jhowell]

Originally Posted by RbnJrg

The only issue is with Kindle Previewer 3.35 (with Kindle Previewer 2.92 all is fine). ... But there is problems with .KFX (with .kf8 all is ok). Amazon must be using a different render engine with .KFX, because with WebKit my aproximation works; ...

The KF8 renderer used in KPR 2.92 is based on Webkit so it is not surprising that it works as you expect.

The KFX renderer is Amazon's own creation and according to the Amazon Kindle Publishing Guidelines, Appendix B: Attributes and Tags Supported by Enhanced Typesetting, the only values it supports for the "white-space" property are "nowrap" and "normal".

[Tex2002ans]

Originally Posted by RbnJrg

In my test with ADE 4.5 I didn't notice anything with

<p>—<span class="ps">&nbsp;</span>Lorem ipsum dolor sit amet, consectet...</p>

------------

p {
  text-align: justify;
}

.ps {
  white-space: pre;
}

Just confirmed.

In ADE:

Using &nbsp; didn't stretch.

Using 1 or more normal space (as the previous examples), you get the stretchiness.

I attached an EPUB using your code + various amounts of normal spaces.

Originally Posted by RbnJrg

The solution is not intended to be applied in a middle of a sentence, just at the beginning.

Hmmm, I'm not familiar enough with languages that use this "quotation dash" convention.

Is it guaranteed they always begin the line? These types of dashes can't occur in the middle of paragraphs?

Because wrapping the &nbsp; in a <span> line-breaks in ADE... which defeats half of the actual functionality!

[RbnJrg]

Originally Posted by Tex2002ans

Just confirmed.

In ADE:

Using &nbsp; didn't stretch.

"O thou, man of little faith"

Hmmm, I'm not familiar enough with languages that use this "quotation dash" convention.

Is it guaranteed they always begin the line?

Not always (but generally, they do). Sometimes dialogs that use quotation dash start in a middle of a sentence. But in a middle of a sentence, is not important the aligment because the answer won't start at the same place of the question, one line below. The issue is important in cases where the dialogs start at the beggining of a line.

These types of dashes can't occur in the middle of paragraphs?

Yes

Because wrapping the &nbsp; in a <span> line-breaks in ADE... which defeats half of the actual functionality!

The solution based on

—<span class="ps">&nbsp;</span>Some text here

works perfectly in ADE even in the middle of a sentence. I repeat you, the only issue is with .KFX (with .kf8 all is ok); I still couldn't find a fix for that format.

By the way, if you in the class "ps" use the following properties:

.ps {
  white-space: pre;
  background: red;
}

you'll see how the space is treated in any render engine. It's very interesting what Kindle Previewer 3.35 does with different size of fonts and different fonts. The property "white-space: pre" is not being supported. As I said before, Amazon seems not to be using WebKit with .KFX. Maybe in future releases of KP that drawback is removed.

[jhowell]

Originally Posted by RbnJrg

you'll see how the space is treated in any render engine. It's very interesting what Kindle Previewer 3.35 does with different size of fonts and different fonts. The property "white-space: pre" is not being supported. As I said before, Amazon seems not to be using WebKit with .KFX. Maybe in future releases of KP that drawback is removed.

I did some testing with the Kindle Previewer and had good results there by replacing the non-breaking space with a figure space ( &#x2007; ). KFX treats that as having a fixed width.