freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] what old/new FontVal says about these fonts


From: Werner LEMBERG
Subject: Re: [ft-devel] what old/new FontVal says about these fonts
Date: Mon, 02 Jan 2017 08:39:10 +0100 (CET)

[Please stay on the list!]

> As one of the core developers of freetype, you have noticed that the
> specs don't achieve fail-safe quality.  It's full of open questions
> and some definitions even contradict each other.  It's in no way
> possible to brain-dead strictly follow definitions.

This is correct, but...

> Having this said, it's clear that a side-notice indicating that any
> font should include hmtx really means that any font should include
> the metrics appropriate for the script writing direction(s).  This
> would be vmtx for vertical scripts, as clarified in the OpenType
> recommendations section of the specs:
> 
> https://www.microsoft.com/typography/otspec/recom.htm#cjk
> 
> Forcing them (fonts for vertical scripts) to include horizontal
> metrics they don't need would be exactly as dumb as forcing
> horizontal fonts to include vmtx.

... but I think you are wrong here.  First of all, not all systems
contain vertical writing support.  Second, even if a script is
intended for vertical writing, it is always a good idea to make it
possible to place them glyph by glyph in a horizontal context (for
example, consider an English textbook for learning Mongolian).  Third,
I would like to be able to view exotic fonts with my font viewer even
if it doesn't support vertical scripts.

Two remarks regarding inconsistencies with the OpenType specification.

 . There exists an annotated OpenType specification at

     https://github.com/adobe-type-tools/aots

   which discusses implementation problems.

 . If you find problems in the specification, please contact Peter
   Constable from Microsoft, who is actively maintaining the current
   version.  [Alas, this doesn't currently hold for the TrueType
   bytecode stuff.]

> From what I've seen so far, freetype aims to support old file
> formats in preference over current standardization status
> (especially for truetype hinting interpreter, please see the
> comments in ttptinst.pas if you find the time, or read my "bug
> report" about the MIRP-instruction again).

How do you get this impression?  FreeType wants primarily to support
the current font world, while still being able to correctly display
old, or even deprecated font formats.

Regarding your MIRP stuff: As I mentioned then, I need time to really
investigate the issue.  Releasing 2.7.1 was more important (and bug
reports for 2.7.2 are already streaming in), sorry.

> So it really sounds like an "impossible" decision to rely on hmtx
> availability: Pretty much of your code already does adress things
> not defined in the specs.

Well, I try to *sanitize* broken fonts if possible.  This is not the
same as deliberately support non-standard stuff.  In particular, if
major platform X supports a particular font (that would be considered
broken if you exactly follow the specification), I try to do the same.
As this thread shows, there still do exist fonts that FreeType can't
display but which other major platforms do handle.

>> What topic, what question?
> 
> Assume old fonts without hmtx.
>
> For example, because it was was made by people not so experienced
> with font engines, probably using freeware tools.  Then these font
> metrics might look like overkill: One rectangle is enough to
> position outlines in a string.  They probably would have defined a
> rectangle and would have visually positioned the glyph outline
> inside it (probably even optimizing for some false, probability
> based kerning).
> 
> Do you now of such fonts, or can we safely assume that all font
> tools have been aware of hmtx, with a constant (probably ebe
> platform independent) rasterizer behaviour all over the years?

I can assure that *all* (and I really mean *all*) outline TTFs *must*
have a `hmtx' table, without any exception.

[The code for incremental font handling doesn't need a `hmtx' table
 because the metrics are handled externally (by Ghostscript), and
 FreeType only sees a specially massaged stream of glyph data.]

> Shouldn't the answer to this question also be the answer to FT's (in
> contrast to my 4-week old project) fallback behaviour on missing
> hmtx for horizonatal fonts?

There is no planned `fallback'.  It's a possible sanitizing step that
I'm too lazy to implement.

>> Note that in the Western world we had Xmas and New Year holidays.
> 
> Gruss aus Osnabrück, Germany

Grüße aus Wien :-)


    Werner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]