Centered initial caps?

[HarryT]

Originally Posted by Hitch

As in? You mean, applying styles, to a ligature only, Harry, or am I misunderstanding you?

As in if you had, to pick a random example, the word "flight", with the "f" as a drop cap (or a raised cap) and the "l" as a normal letter, one would hope that the rendering engine would have the sense not to try to substitute the "fl" ligature for the letters "f" and "l".

[Hitch]

Originally Posted by HarryT

As in if you had, to pick a random example, the word "flight", with the "f" as a drop cap (or a raised cap) and the "l" as a normal letter, one would hope that the rendering engine would have the sense not to try to substitute the "fl" ligature for the letters "f" and "l".

Oh, I think you can be fairly sure that ...well, no. I oughtn't say that, but I'd be very, very surprised if any rendering engine did that, because, as you rightly pointed out, they have different CSS. The BFL/RI/DC will have a span on it, with a character style, or whatever you want to call it.

BUT, two virgin letters? Hansel and Gretel, out there, unprotected? Oh, yeah. They'll get snapped up in a ligature cottage and baked, you betcha.

Hitch

[JSWolf]

Originally Posted by Hitch

You know, Jon, maybe you don't realize it, but I think you've kind of insulted me twice now, on this thread, about ligatures. Do you think you could take a moment, on your next post, and make sure you're not inadvertently trying to get up my nose? TY. I realize that you think of me being geeky, and not print-layout-y, but I'm not a total moron.

UTF-8. If you export ligatures, you get UTF-8.

I'm sorry if I've insulted you. It was not my intention. All I'm doing is trying to get on the same page so I understand what you are saying. What I was thinking did not match what I was reading.

Ligatures (from what I understand) only work when the pairs are naked next to each other. <b>fl</b> should give a ligature as fl is a common ligature. But if it was <b>f</b><b>l</b> then there won't be any ligature.

[Hitch]

Originally Posted by JSWolf

I'm sorry if I've insulted you. It was not my intention. All I'm doing is trying to get on the same page so I understand what you are saying. What I was thinking did not match what I was reading.

Knowing you as I do, I figured that was the case. That's why I asked you to think, before you push "Submit reply," because I didn't think that you intended to do that. Pax.

Ligatures (from what I understand) only work when the pairs are naked next to each other. <b>fl</b> should give a ligature as fl is a common ligature. But if it was <b>f</b><b>l</b> then there won't be any ligature.

That's absolutely right, from what I've seen. On the other hand, with ligatures now showing up, in ET (Enhanced Typography) books...(I feel like we should be cueing the Jaws theme music here....)

And where are you...when you ask about the Ligs, where are you exporting from-->To, that you can't regex them?

Hitch

[JSWolf]

Originally Posted by Hitch

Knowing you as I do, I figured that was the case. That's why I asked you to think, before you push "Submit reply," because I didn't think that you intended to do that. Pax.



That's absolutely right, from what I've seen. On the other hand, with ligatures now showing up, in ET (Enhanced Typography) books...(I feel like we should be cueing the Jaws theme music here....)

And where are you...when you ask about the Ligs, where are you exporting from-->To, that you can't regex them?

Hitch

How would you regex ligatures other than to maybe surround one letter with a <span> so if cannot happen?

[Hitch]

Originally Posted by JSWolf

How would you regex ligatures other than to maybe surround one letter with a <span> so if cannot happen?

OH! Ohohohohoh! I see. No wonder we're not communicating. ("Who's on first...") I'm talking about regexing ligatures OUT, from content we receive to convert; you're talking about putting in prophylactic code/regex, to prevent ligatures from being created.

The Ligature Condom, in other words. Or the Ligature Morning-After Pill. We're at opposite ends of the spectrum, Jon, in what we're each talking about.

NOT a CLUE. I mean, you've suggested the only thing I can think of--put a span around all the 'fs" or "ts" or (insert one letter of a letter pair here), to prevent it. And honestly, man...that's a dog to do, and it would probably blow up MOBI format, even though this is the ePUB forum. (Mobi has a not-publicly-defined-but-real span limit.)

No idea at all. I think that sans the spans, you're stuck with it. (n.b.: you don't have to be. At the moment, thus far, I have only seen them show up when Georgia font is selected. Presumably, Garamond and Baskerville shan't be far behind, but for now, you can switch to a different font and you won't see the ligs.)

Hitch

[nabsltd]

Originally Posted by HarryT

I would have thought that any decent rendering engine would have the sense not to use a ligature if the two letters of the pair had different styles applied to them.

The HTML rendering engine merely enables the TrueType/OpenType "liga" feature with it's font-renderer. It has no effect if that table isn't in the font, and only does what the table says it should do, which means it displays ligatures only for pairs that map to a ligature glyph.

Here's the entire ligature substitution table from one Adobe font:

  sub T h -> T_h;
  sub f f b -> f_f_b;
  sub f f h -> f_f_h;
  sub f f i -> f_f_i;
  sub f f j -> f_f_j;
  sub f f k -> f_f_k;
  sub f f l -> f_f_l;
  sub f f t -> f_f_t;
  sub f b -> f_b;
  sub f f -> f_f;
  sub f h -> f_h;
  sub f i -> f_i;
  sub f j -> f_j;
  sub f k -> f_k;
  sub f l -> f_l;
  sub f t -> f_t;
  sub f f_t.alt -> f_f_t;
  sub Tcedilla h -> Tcommaaccent_h;
  sub Tcaron h -> Tcaron_h;
  sub longs longs i -> longs_longs_i;
  sub longs longs l -> longs_longs_l;
  sub longs b -> longs_b;
  sub longs h -> longs_h;
  sub longs i -> longs_i;
  sub longs k -> longs_k;
  sub longs l -> longs_l;
  sub longs t -> longs_t;
  sub longs longs -> longs_longs;
  sub gamma gamma -> gamma_gamma;
  sub lambda lambda -> lambda_lambda;

CSS is just starting to support OpenType features, which should allow an author to override the renderer defaults for ligatures, etc., in a compliant system. OpenType features also allow fonts to do many things that make for much simpler code. The following renders like the attached image, if your renderer supports the CSS, and you have a font that has the feature (Adobe's New Century Schoolbook does):

<style>
.myfraction {
font-variant-numeric: diagonal-fractions;
}
</style>

<p><span class="myfraction">1/2 1/4 3/4 11/32</span></p>

Originally Posted by pdurrant

I'm all for people trying designs and asking whether it can be done. It helps to show either that the ePub spec is good for a wide variety of ebook design, or that it is not.

Personally, I think it's vastly over complicated for 90% of books. And that the complications don't actually help very much with complex page layout, as HTML/CSS wasn't designed from the point of view of high quality typography/page layout.

One thing that should have been added to the spec is that anything that is considered "body text" (i.e., the text of the book needed to read and understand the story, that in a print book is all set in the same typeface and size) should have been required to be marked as such in some way (e.g., adding another item to the "class" attribute, adding an "epub:" attribute of some kind, etc.).

That way, body font changes, font resizing, and line spacing changes by the reader software would only affect those parts of the text. This would solve a lot of the problems we have with the "runaway font size" for initial caps, chapter headings, etc., since there reader software could have an option to only resize them if they are smaller than the chosen body text size.

Basically, the semantic tags currently in EPUB (like epub:section) are useless to 99% of reader software, while ones that would really help with many of the problems don't exist.

[JSWolf]

Originally Posted by nabsltd

CSS is just starting to support OpenType features

The problem with that is that the versions of ADE for Windows or MAC that support any of these features also supports a DRM that cannot be removed and cannot be used in most Readers. So while CSS can do more, you risk not being able to read your eBooks anyplace else but your computer.

The other problem (forgetting DRM) is that a lot apps (for tablets) and Readers are using an older RMDSK and thus, even if you used OpenType features, they may not work in the majority of software that most people will be reading the eBook. if you could get all the apps and all the Readers up to the latest RMDSK, then yes, OT features in CSS would be great.

[Hitch]

Originally Posted by JSWolf

The problem with that is that the versions of ADE for Windows or MAC that support any of these features also supports a DRM that cannot be removed and cannot be used in most Readers. So while CSS cn do more, you risk not being able to read your eBooks anyplace else but your computer.

The other problem (forgetting DRM) is that a lot apps (for tablets) and Readers are using an older RMDSK and thus, even if you used OpenType features, they may not work in the majority of software that most people will be reading the eBook. if you could get all the apps and all the Readers up to the latest RMDSK, then yes, OT features in CSS would be great.

Jon's quite right about this. The biggest issue with the spec is...that nobody bothers to really follow the spec. It's like train schedules in Mexico--a suggestion. It's a shame, really, and it drives people like me bonkers, because we get squeezed in-between clients at one end of the spectrum ("I want a book that has multimedia, ligatures, columns, visual poetry and oh, yeah, a partridge in a pear tree!"), the device-makers/eRetailers ("We're Apple. We'll just do whatever we goddamn well please.") and the spec ("This is this week's ePUBcheck, and, oh, yeah, if you're something like Lulu, you'll use ePUBcheck 1.0, for5 years.").

Seriously, it's a bit like being a juggler with one eye and one spastic hand.

Hitch

[JSWolf]

Adobe can upgrade ADE (RMDSK) all they want, but until all the apps and all the Readers upgrade as well, it won't matter. Basically, we have to use what's built into ADE 2.0 because we have no idea what version is going to be in use by the people reading. The problem is one of stagnation. Bluefire is a good example. It is using some version 3 RMDSK, but I doubt it will ever use the latest version. Kobo is using maybe some version 3 RMDSK but I doubt we'll ever see the latest version used. So what has to be done is to have to use less features because otherwise they won't work for a majority of users.

Now we have Apple and a new set of issues. iBooks was a problem when the 1st gen iPad stopped being supported because Apple didn't make proper hardware back then. Eventually it because OK to stop supporting iBooks on a 1st gen iPad. But, not we'll have iPad 2-4 in use with an older iBooks and yes, they will have to be supported even if iBooks gets more features and/or bug fixes. Apple will never release a new iBooks for these older models even if it's feasible to do so with iOS 10.

[sherman]

I thought I would have a go at this, after all, how hard could it be...?

Yeah, went about as well as everybody else's attempts did.

This would be easy if there was a some css property like margin and padding that measured from the centre of an element, instead of the edge. I don't know why such an option doesn't already exist, it can't be rocket science to implement. Simply do the existing padding & margin calcs, then subtract half the box width (or height) from the appropriate side of the box.

Also would be a trivial task for JavaScript, but that's a no-go for ebooks.

If one wanted to implement this, the closest I got was a modification to nabsltd's solution in post #15. The idea is, like others have mentioned, is to have different CSS for each initial letter. (actually, the rest of the paragraph)

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>

<style>
p   {margin:0; padding:0;}

.para-dropcap {
	font-family: serif;
	text-align: center;
	font-size: 4.6em;
	font-weight: bold;
	line-height: 1;
}
.para-chapterFirst {
	text-indent: 50%;
	text-align: justify;
	margin-top: -1.75em;
	margin-bottom: 0.1em;
}
.e {
	margin-left: 1.4em;
}
.w {
	margin-left: 1.4em;
}
.t {
	margin-left: 0.9em;
}
.i {
	margin-left: 0.9em;
}
.tts {
	display: none;
}
</style>

</head>
<body>

<p class="para-dropcap">E</p>
<p class="para-chapterFirst"><span class="e"><span class="tts">E</span>nter all ye who would ... yadda yadda
 yadda yadda yadda yadda yadda yadda yadda yadda yadda yadda yadda
 yadda yadda yadda yadda yadda</span></p>
<p class="para-dropcap">W</p>
<p class="para-chapterFirst"><span class="w"><span class="tts">W</span>est of ... yadda yadda
 yadda yadda yadda yadda yadda yadda yadda yadda yadda yadda yadda
 yadda yadda yadda yadda yadda</span></p>
<p class="para-dropcap">T</p>
<p class="para-chapterFirst"><span class="t"><span class="tts">T</span>esting the centering ... yadda yadda
 yadda yadda yadda yadda yadda yadda yadda yadda yadda yadda yadda
 yadda yadda yadda yadda yadda</span></p>
<p class="para-dropcap">I</p>
<p class="para-chapterFirst"><span class="i"><span class="tts">I</span>n the still ... yadda yadda
 yadda yadda yadda yadda yadda yadda yadda yadda yadda yadda yadda
 yadda yadda yadda yadda yadda</span></p>
</body>
</html>

This solution does scale with font size. It does not scale with different font families though, so embedding font used for initial caps would be recommended.

I don't know whether TTS engines ignore items that are hidden by "display:none", so the 'tts' spans may be superfluous.

[JSWolf]

There is no need to specify serif as the font family. serif is the default and besides, that may limit what people can do.

[sherman]

Originally Posted by JSWolf

There is no need to specify serif as the font family. serif is the default and besides, that may limit what people can do.

Note Jon that serif is only specified for the initial letter. Think of it as a placeholder for the embedded font that would actually be used.

[DiapDealer]

Originally Posted by Notjohn

Or the belief that an apostrophe is a prime mark.

Says the person who claimed an &apos; entity creates a prime mark.

[Tex2002ans]

Originally Posted by DiapDealer

Says the person who claimed an &apos; entity creates a prime mark.

Nothing to see here.