Re: [HarfBuzz] Streamlining hb_font_t some more

[Behdad Esfahbod]

On 15-10-26 08:41 AM, Werner LEMBERG wrote:
>>> Knuth knew *very well* what he was doing, and the TeX typesetting
>>> >> model works just fine for almost all cases, even more than 30 years
>>> >> later.
>> > 
>> > That is such a big claim, judging by the amount of people strugling with
>> > TeX line spacing on tex.stackexchange.com:
>> > http://tex.stackexchange.com/questions/tagged/line-spacing
> Hehe :-) Actually, I've meant the simple idea of using glyph boxes
> glued together to form a line, where lines normally have a fixed
> baseline-to-baseline distance.

But that's exactly what TeX isn't...  Anyway, I'll follow up in other messages.
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Simon Cozens]

On 27/10/2015 00:37, Nikolay Sivov wrote:
> But probably more important is that this functionality doesn't seem 
> to belong to harfbuzz in a first place, as it never needs global 
> metrics internally (or does it?).

No, it doesn't need these metrics internally. If Harfbuzz just sticks to
text shaping, then I agree that global font metric functions shouldn't
be there. On the other hand, if Harfbuzz wants to be providing the
information that layout engines need, then it absolutely should be able
to tell you about global font metrics. But in that sense, the recent
work on OT font functions isn't necessary either, because other
libraries easily provide this.

> If you only need a couple of fields it's easy to get them manually 
> from font blob.

Eh, I don't know you about you but the reason I use libraries is to
abstract away this kind of low-level grubbing around... But yeah,
Freetype already does this. I just left it was a shame that something
already had my font open and already had an OpenType parser ready to go,
and it couldn't tell me what I wanted.
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Martin Hosken]

Dear Simon,

> In InDesign, both (1) and (2) get 12 x 1.2 = 14.4pt interline space.
> This means that the descender of the "p" in "ipsum" will bump into
> letters on the next line. That's clearly wrong.
> 
> In the CSS model, both (1) and (2) get half leading added to the top and
> the bottom of the first line. So there is a gap between the first and
> second lines of (1) even though there is no large descender using that
> gap. That's not *wrong* but I don't like it. Imagine a large drop-cap
> "T" at the start of a paragraph - the line spacing after it becomes
> inconsistent.

Another approach is to say the ascent and descent of a line is the max(ascent, 
for all font ascents) and max(descent, for all font descents) on the line.

> I am not a typographer, I just play one on the Internet, so I am not
> sure what someone who was actually typesetting a book would do in that
> situation. My guess would be that they would, basically, do what SILE
> does right now (and what TeX does; perhaps Knuth knew what he was doing
> after all) - use consistent 14.4pt (or whatever) line spacing in
> situation (1) and use larger line spacing which fits in the descender in
> situation (2). But I would have to ask a real typesetter to know.

I like this, but as stated by Werner, if you think the OS/2 values don't make 
sense, then you could use the font bounding box and add 1pt interline gap or 
some such, as a fall back.

GB,
Martin
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Jonathan Kew]

On 26/10/15 15:37, Nikolay Sivov wrote:

On 26.10.2015 11:30, Simon Cozens wrote:

On 09/10/2015 15:09, Khaled Hosny wrote:

should just use the typographical ascender/descender of the font and
hence not
need glyph bounding boxes in Sile at all.


Yes please, an approach similar to what browsers do would be much
appreciated.


OK; I've implemented support in Harfbuzz for getting these metrics out
of the OS/2 table.


I don't think it's that simple, according to specs you need to check
with fsSelection (bit 7), and use sTypo* metrics only when this bit is
set. But of course there's no guarantee that font was generated properly
and sTypo* values are meaningful when this bit is set or garbage if it's
not. Also this bit selector is supposed to be consistent with os/2
version being >= 4; otherwise an option is to use usWin* metrics. And
usWin* metrics are broken too sometimes, just recently I had to fix and
issue when signed value was written to unsigned usWinDescent, which
won't play nice as you can imagine. Also there is an 'hhea' table that
could provide 'similar' functionality, but not always...


Indeed. It's a mess out there.


But probably more important is that this functionality doesn't seem to
belong to harfbuzz in a first place, as it never needs global metrics
internally (or does it?). If you only need a couple of fields it's easy
to get them manually from font blob.


I'm inclined to agree. There's no single "clearly right" algorithm for 
deciding what metrics to use, and it's likely that the "best" answer 
will depend on the nature of the client application (what's appropriate 
for a plain-text editor may be different from what's appropriate for a 
web browser; and a typesetting application may want something different 
again).


Reading the relevant fields from font tables isn't hard, given a 
"get_table" function. The tricky part is deciding which of the 
potentially-conflicting values to use, and we shouldn't put those 
heuristics into harfbuzz, which cannot know what's likely to be most 
appropriate for the client.


(Sure, any given client could still ignore the harfbuzz API and do its 
own thing. But putting such an API into harfbuzz will tend to give the 
impression that it's the "correct" thing to use, and may tempt app 
designers to ignore an issue to which they should actually be giving 
conscious attention.)


JK


___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Nikolay Sivov]

On 26.10.2015 11:30, Simon Cozens wrote:

On 09/10/2015 15:09, Khaled Hosny wrote:

should just use the typographical ascender/descender of the font and hence not
need glyph bounding boxes in Sile at all.


Yes please, an approach similar to what browsers do would be much
appreciated.


OK; I've implemented support in Harfbuzz for getting these metrics out
of the OS/2 table.


I don't think it's that simple, according to specs you need to check 
with fsSelection (bit 7), and use sTypo* metrics only when this bit is 
set. But of course there's no guarantee that font was generated properly 
and sTypo* values are meaningful when this bit is set or garbage if it's 
not. Also this bit selector is supposed to be consistent with os/2 
version being >= 4; otherwise an option is to use usWin* metrics. And 
usWin* metrics are broken too sometimes, just recently I had to fix and 
issue when signed value was written to unsigned usWinDescent, which 
won't play nice as you can imagine. Also there is an 'hhea' table that 
could provide 'similar' functionality, but not always...


But probably more important is that this functionality doesn't seem to 
belong to harfbuzz in a first place, as it never needs global metrics 
internally (or does it?). If you only need a couple of fields it's easy 
to get them manually from font blob.

___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Werner LEMBERG]

>> Knuth knew *very well* what he was doing, and the TeX typesetting
>> model works just fine for almost all cases, even more than 30 years
>> later.
> 
> That is such a big claim, judging by the amount of people strugling with
> TeX line spacing on tex.stackexchange.com:
> http://tex.stackexchange.com/questions/tagged/line-spacing

Hehe :-) Actually, I've meant the simple idea of using glyph boxes
glued together to form a line, where lines normally have a fixed
baseline-to-baseline distance.  And yes, the fine details of line
spacing can be overwhelming.

>> Given that the typographic values from the `OS/2' SFNT table are
>> crap in far too much fonts, and that Apple and MS differ on the
>> right approach, I would really not using it.  Your (1) and (2) are
>> the way to go, IMHO.
> 
> I have only seen a handful of utterly broken fonts, the rest of the
> world are doing just fine.

OK.  I'm certainly biased as the FreeType maintainer, seeing far too
much broken fonts...


Werner
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Khaled Hosny]

On Mon, Oct 26, 2015 at 05:30:20PM +0900, Simon Cozens wrote:
> On 09/10/2015 15:09, Khaled Hosny wrote:
> >> should just use the typographical ascender/descender of the font and hence 
> >> not
> >> need glyph bounding boxes in Sile at all.
> > 
> > Yes please, an approach similar to what browsers do would be much
> > appreciated.
> 
> OK; I've implemented support in Harfbuzz for getting these metrics out
> of the OS/2 table.
> 
> Now that I've fiddled about with it, I don't agree that the correct way
> to determine line space for *print* is the way that browsers do it - I'm
> actually more convinced that using glyph metrics makes the most sense.

The problem with using glyph metrics is that you don’t have consistent
line spacing, for example in Arabic with a font like Amiri some lines
can contain high glyphs with stacked marks and some not and you end it
with big interline spacing between some lines, a very bad result
overall. I had to jump through hoops to get anything remotely consistent
and (by forcing the line spacing through all the document to be as big
as the biggest one and it looks rather ugly). TeX’s idea is to avoid
overlap, but this assumes that just because a line have a few tall
glyphs, it will overlap with previous line, but in practice this rarely
happens, because there are usually enough gaps in the other line to
accommodate those glyphs.

On the web I just get proper line spacing out of box, and when my
document requires bigger line spacing than the default (fully vocalised
text, for example), I just set the CSS line-spacing to a good value and
get a consistent result.

> The problem comes when you have mixed font sizes (not something that
> really *should* happen in print, I know, but I still want to do the
> right thing when it does). The question is, what is the right way to lay out
> 
> 1) \font[size=30pt]{Lorem} ipsum dolor...
> 
> and
> 
> 2) \font[size=30pt]{Lorem ipsum} dolor...
> 
> In InDesign, both (1) and (2) get 12 x 1.2 = 14.4pt interline space.
> This means that the descender of the "p" in "ipsum" will bump into
> letters on the next line. That's clearly wrong.

You can always have a way to set the interline spacing overriding the
automatic calculation, just like in CSS (a sane way to do it, not the
convoluted interdependent parameters that TeX uses and only ~2 persons
in the world understand them).

Regards,
Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Khaled Hosny]

On Mon, Oct 26, 2015 at 03:59:54PM +0100, Werner LEMBERG wrote:
> 
> > I am not a typographer, I just play one on the Internet, so I am not
> > sure what someone who was actually typesetting a book would do in
> > that situation.  My guess would be that they would, basically, do
> > what SILE does right now (and what TeX does; perhaps Knuth knew what
> > he was doing after all) - use consistent 14.4pt (or whatever) line
> > spacing in situation (1) and use larger line spacing which fits in
> > the descender in situation (2).  But I would have to ask a real
> > typesetter to know.
> 
> Knuth knew *very well* what he was doing, and the TeX typesetting
> model works just fine for almost all cases, even more than 30 years
> later.

That is such a big claim, judging by the amount of people strugling with
TeX line spacing on tex.stackexchange.com:
http://tex.stackexchange.com/questions/tagged/line-spacing

> Given that the typographic values from the `OS/2' SFNT table are crap
> in far too much fonts, and that Apple and MS differ on the right
> approach, I would really not using it.  Your (1) and (2) are the way
> to go, IMHO.

I have only seen a handful of utterly broken fonts, the rest of the
world are doing just fine.

Regards,
Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[John Labovitz]

On Oct 26, 2015, at 4:30 AM, Simon Cozens  wrote:

> I am not a typographer, I just play one on the Internet, so I am not
> sure what someone who was actually typesetting a book would do in that
> situation. 

I’ve been a typographer/typesetter for 30 years, working in both digital 
indirect/batch & direct/WYSIWYG systems, as well as in hand-set metal type. 
Most of my work these days is in book design, and I’m writing software (in 
Ruby, using Harfbuzz) to help me do that.

In most projects, I might start out with default line spacing (whether from a 
font or from a simple formula, like the usual 120% rule), but I’ll almost 
always change that to an explicit value (say, 12/15) once the project evolves 
past a simple mockup. Optimum line spacing is determined by many factors, 
including font style, point size, line measure, page proportions, etc. In other 
words, there *is* no default — at least for the kind of projects that 
typographers work on.

What’s far more important to me is control and predictability — I want to 
specify exactly where a line starts on a page (usually by ascender/cap height), 
and then ensure that successive lines are vertically aligned by baselines. So 
line spacing comes out of those issues, not out of a somewhat arbitrary 
default. You can imagine how both TeX and CSS drive me crazy in this regard. ;-)

So, although it’s nice to have minimally useful defaults (so that lines don’t 
overlap, for example), it’s probably *non*-typographers who really need these.

Hope this helps,
—John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Behdad Esfahbod]

On 15-10-09 12:33 PM, Jonathan Kew wrote:
> 
> You probably want to be using the "typographic" metrics from the OS/2 table,
> if present, with the hhea metrics as a fallback for fonts that don't have
> OS/2. (They're rare, but can exist at least on OS X.)

Jonathan,

Can you please point me out to the exact logic you use?  I want to implement
the same.

Thanks,

behdad
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Simon Cozens]

On 10/10/2015 01:33, Jonathan Kew wrote:
> You probably want to be using the "typographic" metrics from the OS/2
> table, if present, with the hhea metrics as a fallback for fonts that
> don't have OS/2. (They're rare, but can exist at least on OS X.)

Hmm... that's something it doesn't look like Harfbuzz will help me with
at all.

Behdad, how would your suggestion to use the font's typographic metrics
work in practice? Do I need to go back to FT for this? Wasn't the whole
point to get away from FT?

S

___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Khaled Hosny]

On Thu, Oct 08, 2015 at 11:54:09AM -0400, Behdad Esfahbod wrote:
>   So, from my
> point of view, you should NOT use this for line height calculation.  You
> should just use the typographical ascender/descender of the font and hence not
> need glyph bounding boxes in Sile at all.

Yes please, an approach similar to what browsers do would be much
appreciated. TeX way of handling interline spacing has always been
cumbersome and confusing (not that I know exactly what SILE do now, but
the further from TeX way here the better).

Regards,
Khaled
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Jonathan Kew]

On 9/10/15 14:32, Simon Cozens wrote:

On 09/10/2015 15:09, Khaled Hosny wrote:

On Thu, Oct 08, 2015 at 11:54:09AM -0400, Behdad Esfahbod wrote:

   So, from my
point of view, you should NOT use this for line height calculation.  You
should just use the typographical ascender/descender of the font and hence not
need glyph bounding boxes in Sile at all.


Yes please, an approach similar to what browsers do would be much
appreciated. TeX way of handling interline spacing has always been
cumbersome and confusing (not that I know exactly what SILE do now, but
the further from TeX way here the better).


OK. SILE currently does the same as TeX, and I agree that it's confusing.

I have just released SILE 0.9.3, so now I have a clean slate to play
with. I have merged the new shaping pipeline (sending whole paragraphs
to Harfbuzz) and moved over to HB OT functions, dropping the Freetype
dependency. This makes a *lot* of things happier. Bidi support is much
better, and it's now *much* faster too: my 28 page test document which
used to take 15 seconds in 0.9.3 now takes 5 seconds.

I'm happy to look at using the font ascender/descender metrics for line
heights - is there a good way to get those values out of Harfbuzz yet?
Grepping the repository doesn't turn up much. (There's also typographic
line gap information in the _hea table - should I be using that?)


You probably want to be using the "typographic" metrics from the OS/2 
table, if present, with the hhea metrics as a fallback for fonts that 
don't have OS/2. (They're rare, but can exist at least on OS X.)


JK

___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Simon Cozens]

On 09/10/2015 15:09, Khaled Hosny wrote:
> On Thu, Oct 08, 2015 at 11:54:09AM -0400, Behdad Esfahbod wrote:
>>   So, from my
>> point of view, you should NOT use this for line height calculation.  You
>> should just use the typographical ascender/descender of the font and hence 
>> not
>> need glyph bounding boxes in Sile at all.
> 
> Yes please, an approach similar to what browsers do would be much
> appreciated. TeX way of handling interline spacing has always been
> cumbersome and confusing (not that I know exactly what SILE do now, but
> the further from TeX way here the better).

OK. SILE currently does the same as TeX, and I agree that it's confusing.

I have just released SILE 0.9.3, so now I have a clean slate to play
with. I have merged the new shaping pipeline (sending whole paragraphs
to Harfbuzz) and moved over to HB OT functions, dropping the Freetype
dependency. This makes a *lot* of things happier. Bidi support is much
better, and it's now *much* faster too: my 28 page test document which
used to take 15 seconds in 0.9.3 now takes 5 seconds.

I'm happy to look at using the font ascender/descender metrics for line
heights - is there a good way to get those values out of Harfbuzz yet?
Grepping the repository doesn't turn up much. (There's also typographic
line gap information in the _hea table - should I be using that?)

Simon
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Behdad Esfahbod]

On 15-10-05 07:35 PM, Simon Cozens wrote:
> On 03/10/2015 01:51, Behdad Esfahbod wrote:
>> So, how does that sound?  I expect that it will only make easier for most
>> clients.  Like to hear what Jonathan has to say.  Chrome, Android, Pango,
>> XeTeX, Sile should all either benefit from this or be unaffected.
> 
> This all sounds great but if it's a question of priorities I would like
> to see more on getting the OT features complete and being able to drop
> FT support - so that means CFF and everything else. That's where the
> real speed increase is; if OT is not a complete replacement for FT, we
> can't use it yet, no matter how fast it is...

Right.  You seem to want glyph bounding boxes, for which we need CFF
implemented.  However, let me point out a conceptual design point that I hope
I can convince you on:

In TeX font model, glyphs contain a *logical* bounding box.  That's what's
used in the line stacking.  In OpenType, we don't have that.  We only have ink
bounding box.  For TrueType, the bounding box is written out in the font.  One
can lie about the ink bounding box and essentially get a logical bounding box
in TrueType fonts.  But that will be a bad font.  In CFF, we just don't have
anything other than the outline, and hence ink bounding box.  So, from my
point of view, you should NOT use this for line height calculation.  You
should just use the typographical ascender/descender of the font and hence not
need glyph bounding boxes in Sile at all.

I'd be happy to elaborate.

behdad
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Simon Cozens]

On 03/10/2015 01:51, Behdad Esfahbod wrote:
> So, how does that sound?  I expect that it will only make easier for most
> clients.  Like to hear what Jonathan has to say.  Chrome, Android, Pango,
> XeTeX, Sile should all either benefit from this or be unaffected.

This all sounds great but if it's a question of priorities I would like
to see more on getting the OT features complete and being able to drop
FT support - so that means CFF and everything else. That's where the
real speed increase is; if OT is not a complete replacement for FT, we
can't use it yet, no matter how fast it is...

S
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

[HarfBuzz] Streamlining hb_font_t some more

[Behdad Esfahbod]

Hi,

So, with the default scale set to upem, I'm now planning to make the following
changes:

  - Make all fonts have a parent; for fonts created with hb_font_create(),
they will default to the hb_font_get_empty() font as their parent.  This
changes the return value of hb_font_get_parent() for most fonts, but I don't
think any clients rely on that.  The get_parent() for the empty font will
continue to return NULL.

  - Optimize how chaining to parent font happens; this is easy and shouldn't
affect any client.

  - Optimize hb-ot-font.  Make it be *really* fast.

  - Add a "canonical-font" per face, eg, hb_face_get_canonical_font().  This
is a immutable font that works in the upem, ie, design, space of the font.

  - Make the canonical-font parent of all fonts created using
hb_font_create().  This will make hb_ot_font_set_funcs() unnecessary and for
the first time, fonts created using hb_font_create() will actually work
properly without explicit set_funcs needed.  Clients can still set their own
functions and things will work as before.  The only difference here will be in
the behavior of functions not implemented by custom font funcs.

The canonical-font will have optimized functions that avoid scaling
completely.  For applications like Sile that want to work in upem space, they
can get the highest performance possible.

The reference-counting between face and canonical-font will become interesting
since they'd need to reference each other, but I have a rough plan in mind.

So, how does that sound?  I expect that it will only make easier for most
clients.  Like to hear what Jonathan has to say.  Chrome, Android, Pango,
XeTeX, Sile should all either benefit from this or be unaffected.

Cheers,
-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Konstantin Ritt]

Sounds just great!

2015-10-02 19:51 GMT+03:00 Behdad Esfahbod :

>   - Make all fonts have a parent; for fonts created with hb_font_create(),
> they will default to the hb_font_get_empty() font as their parent.  This
> changes the return value of hb_font_get_parent() for most fonts, but I
> don't
> think any clients rely on that.  The get_parent() for the empty font will
> continue to return NULL.
>

I do not really understand why...
Do we really want to
while (hb_font_get_parent(font) != hb_font_get_empty())
font = hb_font_get_parent(font);
?


Regards,
Konstantin
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Streamlining hb_font_t some more

[Behdad Esfahbod]

On 15-10-02 06:08 PM, Konstantin Ritt wrote:
> Sounds just great!
> 
> 2015-10-02 19:51 GMT+03:00 Behdad Esfahbod  >:
> 
>   - Make all fonts have a parent; for fonts created with hb_font_create(),
> they will default to the hb_font_get_empty() font as their parent.  This
> changes the return value of hb_font_get_parent() for most fonts, but I 
> don't
> think any clients rely on that.  The get_parent() for the empty font will
> continue to return NULL.
> 
> 
> I do not really understand why...

It removes an "if" conditional from the default callbacks, as they can assume
parent is present.


> Do we really want to
> while (hb_font_get_parent(font) != hb_font_get_empty())
> font = hb_font_get_parent(font); 
> ?

Really depends on what the client is doing.  If they don't care about
processing get_empty() one, they just do one more iteration to get to NULL.

> Regards,
> Konstantin 

-- 
behdad
http://behdad.org/
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz