W3C home > Mailing lists > Public > www-style@w3.org > February 2015

Re: [css-inline] i18n-ISSUE-408: Boxed characters and initial letter properties

From: Florian Rivoal <florian@rivoal.net>
Date: Tue, 17 Feb 2015 18:15:59 +0900
Cc: Richard Ishida <ishida@w3.org>, Dave Cramer <dauwhe@gmail.com>, www-style list <www-style@w3.org>, www International <www-international@w3.org>
Message-Id: <20326934-C858-49E4-9D20-1AF45583A5CC@rivoal.net>
To: Arle Lommel <arle.lommel@dfki.de>

> On 17 Feb 2015, at 17:55, Arle Lommel <arle.lommel@dfki.de> wrote:
> Hi Florian,

Hi Arle,

> Sorry, I wasn't clear. I agree with you entirely. I was just pointing out that you don't do this sort of sizing for most typesetting purposes because it looks ugly, which is why the rendering engines don't do it that way. But what Richard is discussing is clearly an exception to the general rule, and you are absolutely right that it is the “only reasonable thing to do” in this case, even though you wouldn't do it for most other situations.

Agreed, thanks for the clarification.

> Speed shouldn't be an issue, since all the engine has to do is check the actual (versus typographically nominal) bounds and use them. It isn't a complex procedure at all,

I don't know nearly enough about how fonts work, but I expect that writing a character (including combining diacritics) at a certain font size and checking how big the physical bounding box was, or doing the same without actually drawing the character, should be quite easily done.

On the other hand, I wonder if the opposite problem actually works out ok: given a box, what is the largest font size that will result in a character that just fits? Is the mapping between the font size and the actual size of the glyph a simple one, or are fonts able to define it in arbitrarily complicated ways, possibly including not strictly increasing functions? If it is linear or otherwise simply predictable, it will be simple. If it is arbitrary, but required to be increasing, binary searching should still get us there reasonably efficiently. But if it is unconstrained, it will make the problem "interesting".

> but whether rendering engine developers would see it as a worthwhile one to address since it does require specific handling is another matter. Only they could say whether it is worth their while. My guess is that as HTML is used more and more to create an experience somewhat equivalent to print, we should see issues like this becoming more important.

Right. I cannot speak for engine vendors, and I don't know what priority they will assign to such a feature. That said, this feature should only have runtime costs if you actually use it, so I don't expect vendors to push back if someone were to submit a patch implementing it, even if they would not have committed the resources to do it themselves.

 - Florian
Received on Tuesday, 17 February 2015 09:16:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:51 UTC