Rendering Drop Caps

[petrjahoda]

Aha, and that is right because the word is separate in the source itself. But now i understand the problem and will add some merging of those words for search

[JSWolf]

Originally Posted by petrjahoda

Aha, and that is right because the word is separate in the source itself. But now i understand the problem and will add some merging of those words for search

And if you want drop caps and your eBook is ePub3 and you you want to be backwards compatible with ePub2, you need to use a span.

[petrjahoda]

Yes, I understand it now, thank you very much for it, will look into it. Surely it has to have a solution.

[JSWolf]

Originally Posted by petrjahoda

Yes, I understand it now, thank you very much for it, will look into it. Surely it has to have a solution.

My solution is to drop the drop cap. It never works properly anyway. Not with my choice of font and choice of line height.

[petrjahoda]

What would you do in my shoes?
Half the users say drop the drop cap, the other half say solve it.

[JSWolf]

Originally Posted by petrjahoda

What would you do in my shoes?
Half the users say drop the drop cap, the other half say solve it.

I suppose if you want ot try to solve it, you should figure out that it's a drop cap and using the font and the line height, you can render the drop cop overriding the CSS. But you would need different algorithms for some different letters.

My opinion is to just drop it. In most cases it doesn't look good. It would take too much for you to solve it.

[petrjahoda]

OK, fair response, because I already tried to solve it for almost a whole day and I think I solved it.

[pdurrant]

I look forward to trying it. IMO there are several parts to the problem

(1) working out that a drop cap is being attempted
(2) working out the number of lines the drop cap is supposed to be over
(3) setting the size and position of the drop cap so that *for the fonts being used* the baseline of the drop cap is on the baseline of the nth line of text, and that position of the cap height of the drop cap is the same as the position of the the cap height of the first line of text.

I would not expect any drop cap algorithm to handle unusually large descenders (e.g. a swash Q), or make the text wrap to the shape of the drop cap (e.g. A)

[petrjahoda]

I ended up like this
- for any font, the drop cap is rendered in proper size and placed properly, meaning no more overlap to top, etc.
- the number of lines is set by the css of that element, so sometimes it is over 2 lines, sometimes over 3, etc.

[petrjahoda]

And about that search. Can you please send me a file, where it is not working?
I just tried that Eye Spy and searched for multiple word, that are in dropcap and the search works ok.

Like this example, searching for Karse, that is in dropcap and the search returns it without problems.

Surely there has to be a problem with this search, when you are reporting it, but I am not able to find it in any epubs I have, so I would like to look at that problematic epub and that dropcap word, that cannot be found.

JSWolf, can you please send me a book with this problem? Maybe it will be around formatting?

[Falkor]

Originally Posted by pdurrant

I think he means that because there's markup around the drop cap, a search for a word won't find instances of that word that have a drop cap , because the letters in the word aren't contiguous.

Sounds like a poorly implemented search feature.

Originally Posted by pdurrant

(With ePub 3 I think you can do it with CSS styling of first character in a first paragraph, so characters of the word remain contiguous, while in ePub 2 you have to make it a <span>)

My main issue with spans is that they will never look good at all font/line height settings. I only use them as a fall back solution.

First-letter and initial-letter work really well for me in epub3 –*unfortunately my reading device still doesn't support initial-letter. But it works fine in calibre viewer, apple books, thorium, sigil and ADE.

I haven't been able to try it in justread, the app keeps crashing on my computer when I try to finish the initial setup.

My chapter headings are h2, this is what I use:

  h2 + p::first-letter{
    initial-letter: 2;
    -webkit-initial-letter: 2;
    margin-right: 0.3em;
    }

[petrjahoda]

Hi Falkor, the problem with search feature does not exist, the search feature works properly from the beginning.

What do you mean by that 'The app keeps crashing on my computer?'
The app is for iOS and ipadOS, not a computer, it is not supposed to work on a computer and I even have it not allowed in the binary, looks like I have to look into this, because a proper macOS app is planned for summer.

And now I understand, from where are those crashes coming :-).

[petrjahoda]

Found it, a separate checkbox for availability for macOS in the AppStore Connect.
As this app is not supposed to run on macOS, I disabled it now also in the AppStore Connect.
Proper macOS app is planned for summer (with editing functionality).

[Falkor]

Originally Posted by petrjahoda

Hi Falkor, the problem with search feature does not exist, the search feature works properly from the beginning.

Excellent! This does seem to be a widespread issue with reading apps. It's great that you're doing this properly.

Originally Posted by petrjahoda

Found it, a separate checkbox for availability for macOS in the AppStore Connect.
As this app is not supposed to run on macOS, I disabled it now also in the AppStore Connect.
Proper macOS app is planned for summer (with editing functionality).

Ah, so that's why. Looking forward to trying the macOS app

[petrjahoda]

Just a quick sneak peek: for that macOS version, my inspiration is what https://www.panels.app did for comics: scroll down to see how it looks on macOS, that is what I want for epubs (with editing).