valid code but too complicated for e-reader

[cybmole]

I observe that my sony T3 had trouble with opening lines like:
<p class="noindent1">B<small class="calibre10">RINSOP</small> C<small class="calibre10">HURCH WAS</small> locked now. ...

basically, the T3 fails to justify the 1st line, leaves it short when there is visibly room for another word or so.

My observation is that is happens when more than one of the opening words are capitalised i.e. it is the shifting in and out of small class letters that is confusing it.

it is annoying when reading as about 20& of chapter openings are affected & I am not sure of best fix.

it could be that removing the class after the <small would help but I am not sure how well small is honoured in e-readers ?

so does this form part of a larger set of "valid" CSS that should be avoided for max compatibility & if so where would I find more about that ?

I have been fixing the worst annoyances manually by putting everything except the 1st letter into a single small class. the reader copes with that, but composing a regex to automate it is scary.

The publishers rule seems to be that the 1st 3 words go into small, but not any capitalisation.
I manually change the given example to this & its fine:
<p class="noindent1">B<small class="calibre10">RINSOP CHURCH WAS</small> locked now.

[mrmikel]

How does this display in ADE and the Sony Reader Library?

[theducks]

My older ADE (not a Baloney) reader does not do smallcaps, so no worries

IMHO it is safer to use real CAPITALS inside a span set at 85-90%

BTW <small> in not on my cheat sheet or at HTMLDOG

[Jellby]

What does the "calibre10" class say? If it's just "font-size:85%" or something like that, I don't see any problem, and this is a (not unexpected) bug of the renderer. (The <small> element is standard, and allowed, you can find it here.)

But, just for the sake of nitpicking, you should actually write:

B<small class="calibre10">RINSOP</small> C<small class="calibre10">HURCH</small> <small class="calibre10">WAS</small>

as the space should be rendered at the normal font size, and not the reduced fake-small-caps one.

[cybmole]

Originally Posted by mrmikel

How does this display in ADE and the Sony Reader Library?

its ok when viewed in sony reader for PC software ( = ADE 2.0).

it's just bad on the actual e-reader. & I think I experienced it with another book on my old PRS-650 also

the reader will lay out a 1st line which is not justified & which has enough space a the end for another word or so. the rest of the paragraph will be OK

the calibre10 class statement is just setting a font size of 0.7em. If I remove it, the line looks much the same in PC viewer but I've not gone to the trouble of removing it, renaming it & putting both onto the e-reader to compare.

this chapter opening is some kind of "house styling" as it is throughout a series of books by same author / from same publisher

PS the publisher seem to want 3 small caps words but with the 1st letter of some of those words being larger than the rest of the word when the word is a proper noun. The damage seems to be from excluding a 1st letter from small, ( the "C" of Church ) not from also excluding a space.

so in their "house style" an opening of WHEN THE CAT ....would only have a large W, nothing else, but an opening of WHEN FRED SMITH.. would have a large W, F, and S i.e. it would go in & out of small 3 times. ( I have used bold, to illustrate this within this post)

why do you say it s a not unexpected renderer bug ?

[theducks]

Originally Posted by Jellby

What does the "calibre10" class say? If it's just "font-size:85%" or something like that, I don't see any problem, and this is a (not unexpected) bug of the renderer. (The <small> element is standard, and allowed, you can find it here.)

But, just for the sake of nitpicking, you should actually write:

B<small class="calibre10">RINSOP</small> C<small class="calibre10">HURCH</small> <small class="calibre10">WAS</small>

as the space should be rendered at the normal font size, and not the reduced fake-small-caps one.

Thanks, I forgot to check there.

[mrmikel]

What happens if you go through the first line in the calibre editor? If you go character by character, do you see any invisible characters indicated? Not doubting you, wanting to turn over every stone.

[cybmole]

Originally Posted by mrmikel

What happens if you go through the first line in the calibre editor? If you go character by character, do you see any invisible characters indicated? Not doubting you, wanting to turn over every stone.

no it's all clean - & this is retail epub stuff, not dodgy scanned source material.

I actually had a couple of the books in this series as mobi from amazon & I get the same issues with those books after conversion to epub.

hence my original thread title, it's as if the renderer looks at the amount of computation needed to get the 1st line properly typeset & says " too hard , not doing it "

I am aware of other similar instances where a paragraph with an excessive amount of embedded spans & classes will overspill on the reader; you'll lose part of a line as it misjudges the right hand margin. I don't have an example to hand but I can recall having to tweak such things in other books. But in this instance it is an underspill, not an overspill.

[Jellby]

Originally Posted by cybmole

The damage seems to be from excluding a 1st letter from small, ( the "C" of Church ) not from also excluding a space.

My remark about the space was unrelated to the bug, just noting the "right way" to fake the small-caps, which is what that style is supposed to do.

why do you say it s a not unexpected renderer bug ?

Because I have seen similar things before in Adobe-based readers.

[cybmole]

so typesetting 101 question:
in small-caps-done-properly, should there be larger letters to initialise proper nouns, or should everything be in small capitals - all the same size ?

or does each publisher just do their own thing & there's no real standard ?

would my example have been more robust if coded as font-variant:small-caps; not as capitals within a <small> tag or do less e-readers support the former

[mrmikel]

What happens if you get rid of the class"calibre 10" and simply alter small in the CSS? Does that help?

[cybmole]

Originally Posted by mrmikel

What happens if you get rid of the class"calibre 10" and simply alter small in the CSS? Does that help?

I think maybe it would but I'd need to create a copy of the book, edit it, send it to sony reader... or make a test-case "book" with just a few test paragraphs. I may do that if it continues to bug me.

the other way would be to change <small class = "calibre 10" ... </small > to <span class = calibre 10"... </span>

as small is over-ridden by the class code anyway....

I think I did that successfully in some other book

[Jellby]

Originally Posted by cybmole

so typesetting 101 question:
in small-caps-done-properly, should there be larger letters to initialise proper nouns, or should everything be in small capitals - all the same size ?

Smallcaps-done-properly would be:

<span class="smallcaps">Brinsop Church was</span> locked now

(with "span.smallcaps" as font-variant:small-caps). The small-caps variant is ideally a different font style, just as italic or bold, with the particularity that uppercase letters and most symbols look exactly the same as the regular style, but lowercase letters look like scaled down versions of the uppercase letters.

The problem is the Adobe renderer simply ignores font-variant.

would my example have been more robust if coded as font-variant:small-caps; not as capitals within a <small> tag or do less e-readers support the former

It depends on what you consider "more robust". It's less likely to cause the kind of problem you are seeing, or interfere with search or hyphenation. It's also easier to code and maintain. At the cost of not working in most current devices.

But this is a purely aesthetic styling, there's no semantics at all involved, it's just there to make it "look nice". So, in fact, I would not be worried by the fact that it doesn't work (after all, nothing is broken), I would just code this with font-variant:small-caps and enjoy its beauty when and where it works

[Tex2002ans]

Originally Posted by Jellby

But this is a purely aesthetic styling, there's no semantics at all involved, it's just there to make it "look nice". So, in fact, I would not be worried by the fact that it doesn't work (after all, nothing is broken), I would just code this with font-variant:small-caps and enjoy its beauty when and where it works

Back in November we discussed this same thing:

https://www.mobileread.com/forums/sho...&postcount=125
https://www.mobileread.com/forums/sho...&postcount=126
https://www.mobileread.com/forums/sho...&postcount=129

I too align myself with the cleaner code, and it will work where it works (those that support font-variant: smallcaps). Much more maintainable in the long-run.

[cybmole]

thanks - I finally get the difference between <small> and small-caps. If I were a developer I'd want to test which of the current crop of e-readers & tablets can handle small-caps, within the readers' own "original" font - if that's already been done & anyone has a link.please post it...
but if it's true that ADOBE renderer ignores it than that's all of the Sony range ruled out so for my own reading I'll just change <small class= to <span class= & work around it that way.