epub code snippets (html / css)

[JSWolf]

Originally Posted by DiapDealer

Sigil doesn't erase it at all. It just un-entities it... meaning you probably can't see it in the Code View. But it's still there and it still renders properly in the Book View.

The regex expression \x{202f} will find all occurrences of the narrow, non-breaking spaces that you thought were erased (in Code View).

This is all based on Sigil 0.5.3.

Is that Tidy at work again?

[DiapDealer]

Is that Tidy at work again?

No clue. I just learn to work around things like that (once I'm aware of them) rather than dwelling on them.

[roger64]

Thanks all for your infos. It's a big first for me to know something can be unentified but not erased.

I'll try this clever regex expression, it will be an opportunity to use 0.53.

Will for sure come back on it after trials.

Originally Posted by Jellby

I don't know what Sigil does, but my reader (Cybook Orizon, which uses an Adobe engine internally) supports it fine, at least with the fonts I use.

/hopeful / Could you name one of them (if possible, free, regular, serif) ?

supports it "fine" : That's exactly the word to use!

[roger64]

Hi

I just found some information about the narrow no-break space, which is more recent than the thin space and presumably more promising for French writers and about its font support. Here.

Like presumed, ADE is flagging it with a question mark. Even using a supported font (TNR), on my -old- PRS-505, I get the same question marks.

So, if I prepare an EPUB with these narrow spaces, it seems it will be moreless the same as with the thins spaces. Only the "new generation" of e-readers seems to be able to transcribe them correctly. French will have to wait a little...

Or did I miss something?

[Doitsu]

Originally Posted by roger64

So, if I prepare an EPUB with these narrow spaces, it seems it will be moreless the same as with the thins spaces. Only the "new generation" of e-readers seems to be able to transcribe them correctly. French will have to wait a little...

I've always thought that French always requires non-breaking spaces before two-part punctuation characters (e.g. colons, question marks etc.).
Are thin spaces automatically treated like non-breaking spaces? If not, aren't you (theoretically) running the risk that a punctuation character is separated from the preceding word and moved to the next line if the user changes the font size?
BTW, I've read conflicting information regarding the recommended width of a space character before a two-part punctuation character in French. What's the correct width according to your research?

[Toxaris]

Originally Posted by DiapDealer

No clue. I just learn to work around things like that (once I'm aware of them) rather than dwelling on them.

I have put in an issue in the list about this some time ago. In older versions this behavior was not present (0.4.2 or even lower) and I really want to see those entities. If you can't see them, you never know if they are there until the book is already finished and on the readers. I really dislike question marks when they don't have to be there...

[roger64]

Originally Posted by Doitsu

BTW, I've read conflicting information regarding the recommended width of a space character before a two-part punctuation character in French. What's the correct width according to your research?

It's indeed -slightly- conflicting.

It may not be very helpful because it's written in French but it deals with your question. Sorry for feeling unable to translate. Here it is.

[Jellby]

Originally Posted by roger64

/hopeful / Could you name one of them (if possible, free, regular, serif) ?

Now I'm using Minion Pro (not free), but I believe it works with Droid Serif (free) too.

If I remember correctly (I don't have the reader here to try), narrow non-breaking spaces didn't work with the Gen3, and they only work with the Orizon if I enable hyphenation. It seems hyphenation triggers the use of a newer rendering engine, with better font support. When I enable hyphenation narrow non-breaking spaces (and many other kinds of spaces) are turned into question marks.

Have a look here.

[Jellby]

In reality, I'd prefer not to have to include these thin spaces. In LaTeX, for instance, I can just say that I'm writing in French, and automatically all punctuation that needs has some space (non-breaking, of course) added before/after it. I wish there was something similar for ePub (and there's no reason why a rendering engine could not implement it).

[roger64]

Originally Posted by Jellby

In reality, I'd prefer not to have to include these thin spaces. In LaTeX, for instance, I can just say that I'm writing in French, and automatically all punctuation that needs has some space (non-breaking, of course) added before/after it. I wish there was something similar for ePub (and there's no reason why a rendering engine could not implement it).

It would be great. I will ask Henrik Just about it. He is probably familiar about it because he develops Writer2Latex, of which W2X is only a subset.

Thanks for your other answers.

[Jellby]

Actually, what I meant is that the thin spaces shouldn't even be in the code, they're just a display thing. But short of that, adding them when the conversion into ePub is done would be already an improvement.

[roger64]

Originally Posted by Jellby

Actually, what I meant is that the thin spaces shouldn't even be in the code, they're just a display thing. But short of that, adding them when the conversion into ePub is done would be already an improvement.

I published a regex emulating them from  
Just a lookalike. But ADE does not like thinsp and nnbsp so it's just a - clumsy - workaround.

Here is it to be used for example with Sigil as a regex (all html files).

Search ([«]) | ([;!?»])
Replace \1<span class="fine">&nbsp;</span>\2

CSS code is a one-liner:
span.fine {font-size:0.25em;}

[huebi]

Deleted due to moderation issues.

[paxmark1]

In all too many Project Gutenberg .epub 's the blue footnote number is superimposed on the text. This is probably due to their automated usage of epubmaker and their one size fits all settings thereof.

To fix - get into the .css part of the epub (Sigil works well for this). For PG it is /Styles/0.css
The right alignment is incorrect. Amend .footnote .label to have the right position to be at 91%

.footnote .label {
position: absolute;
right: 91%;
text-align: right
}

[jobalcaen]

This is the code I use to center images that have width's set as percentages:

<div class="imagecentre"><img alt="a horse" src="../Images/pic0001.png" /></div>

div.imagecentre
{
margin-left: 25%;
width: 50%;
}

div.imagecentre img
{
width: 100%;
}

When setting a relative image width (such as 50%), create a left margin that is half of the remaining page width. In the example below the image width is 50% of the screen so the left margin is set to 25%.

I found the code at http://adamdscott.com/wrote-about/re...ges-in-ibooks/ and have tested it on: Ibooks, Sony PRS-505, ADE and the firefox epubreader.

At first it seemd like a simple fix but it was hard finding a solution that worked reliably on so many readers.