Re: Font files and vertical text

Dear Mr. Hallikainen,

Thank you for the explanation of the technical background of your question.

The point I have to emphasize is: FreeType is a full-featured font driver
of TrueType and some PostScript fonts, but not a full-featured font driver
of ISO/IEC 14496-22 aka OpenType. OpenType is a mixture of TrueType and
(PostScript's) CFF font and has some extra tables for a fine tuning of
the text layout. The coverage of the FreeType features is basically the
part *without* the extra tables. So if you can find something interesting
in ISO/IEC 14496-22, some can be found in FreeType2 documentations,
but others cannot be found.

--

I'm not familiar with the digital cinema technology, so hard to guess
the detail of your software. The decoder (appropriate term?) is running
on the general purpose operating systems? Or running on the set-top box
like systems? Is it possible to specify the appropriate font to render
the subtitles in the vertical writing mode?

> Most current cinema systems seem to ignore vertical metrics. Instead, they
> appear to place a fixed fractional amount of em between the bounding boxes
> of characters. This works for most characters, but results in extremely
> close spacing for punctuation, ichi, and other characters that do not use
> the full cell.

> Further, most systems are horizontally centering the
> bounding box of each character around a vertical line (X=Hposition).
> Again, this works for most characters, but results in incorrect rendering
> of punctuation.

So, the resulted text is looking like "incorrect-123.png" in attachment?

> It seems like we have found the Y offset between the horizontal origin and
> the vertical origin in the VORG table or by adding the top side bearing to
> yMax.

OpenType has a 2 types in it. One is an extended TrueType, including
"glyf" table which describes the glyph outlines by TrueType instructions.
Another is an extended CFF, including "CFF " table which describes the
glyph outlines by (PostScript-derived) CFF instructions. VORG table was
introduced for the CFF-based OpenType. The spec says as
"This table may be optionally present only in CFF OpenType fonts.
If present in OpenType fonts containing TrueType outline data,
it must be ignored."
( https://docs.microsoft.com/ja-jp/typography/opentype/spec/vorg )
Are you working with CFF-based OpenType for your system?

Anyway, in the design of the FreeType architecture, VORG table is regarded
as an extension in the OpenType, and FreeType does not reflect the info
written in VORG table in the metric calculation. It is similar to the kerning
info in GPOS table. Also, the data in BASE table is not reflected either.
It is not reflected in the FreeType metrics calculation, so you cannot
find anything any examples in FreeType documentations.

FreeType2 has a otvalid module which parse and validate the content of
some OpenType tables (BASE, GDEF, GPOS, GSUB, JSTF), but it does not support
VORG. Also it does not provide the public API to extract the specific value
from that. There was a light-wait library, libotf, to parse the OpenType
extended tables (used for earlier Emacs), but it does not support the VORG
either.

If you want to work with the info in the BASE and VORG table, you would have
to make your parser of them. FT2 can provide the memory image of those table
by FT_Get_Sfnt_Table(), but no API to parse the content. You would have to
parse it by yourself.

>> The x position of the top pen position in the vertical writing mode can
> be calculated by (advance / 2) - bearingX, both can be obtained from hmtx
> table.
> 
> Is bearingX the left side bearing? I'm not seeing why this would be
> subtracted from the AdvanceWidth/2 . It seems that a glyph would typically
> be centered between the horizontal origin and the horizontal origin plus
> the advance width.

Oh, sorry. I made a mistake about the coordination system (I mistook the
origin of the coordination system as the lower left point of the glyph
bounding box). Yes, the half of AdvanceWidth is OK.

Regards,
mpsuzuki

On 2021/05/16 12:01, suzuki toshiya wrote:
> Hi all,
> 
> I got a response from the original questioner, and forward it to the
> list (with permission) for the continued discussion, I would try.
> 
> Regards,
> mpsuzuki
> 
> -------- Forwarded Message --------
> Subject: Re: [Freetype] Font files and vertical text
> Resent-From: [email protected]
> Date: Sat, 15 May 2021 19:51:07 +0000
> From: Harold Hallikainen <[email protected]>
> To: suzuki toshiya <[email protected]>
> 
> Sorry about the repeat! I hit send instead of save draft. Here's more of
> the message.
> 
> Thank you for the excellent information! I am working with the Society of
> Motion Picture and Television Engineers to try to improve the rendering of
> Japanese subtitles in digital cinema. The FreeType tutorials have provided
> me with a lot of the basics of how font files are interpreted.
> 
> Most current cinema systems seem to ignore vertical metrics. Instead, they
> appear to place a fixed fractional amount of em between the bounding boxes
> of characters. This works for most characters, but results in extremely
> close spacing for punctuation, ichi, and other characters that do not use
> the full cell. Further, most systems are horizontally centering the
> bounding box of each character around a vertical line (X=Hposition).
> Again, this works for most characters, but results in incorrect rendering
> of punctuation.
> 
> It seems like we have found the Y offset between the horizontal origin and
> the vertical origin in the VORG table or by adding the top side bearing to
> yMax.
> 
> The X offset between the horizontal origin and the vertical origin seems
> more difficult.
> 
> ISO/IEC 14496-22 2019-1 section 5.7.10 says "The x coordinate of a glyph's
> vertical origin is not specified in the 'vmtx' table. Vertical writing
> implementations may make use of the baseline values in the Baseline
> ('BASE') table, if present, in order to align the glyphs in the x
> direction as appropriate to the desired vertical baseline.
> 
> Section 6.3.1 describes the BASE table as "The Baseline table (BASE)
> provides information used to align glyphs of different scripts and sizes
> in a line of text, whether the glyphs are in the same font or in different
> fonts. To improve text layout, the Baseline table also provides minimum
> (min) and maximum (max) glyph extent values for each script, language
> system, or feature in a font."
> 
> It goes on to state:
> 
> Within the BASE table, a BaseCoord table defines baseline and min/max
> extent values. Each BaseCoord table defines one X or Y value:
> 
> If defined within the HorizAxis table, then the BaseCoord table contains a
> Y value.
> 
> If defined within the VertAxis table, then the BaseCoord table contains an
> X value.
> 
> It appears this is the correct location to determine the X value of the
> vertical origin (X offset from the horizontal origin).
> 
> However, I have not seen any further documentation suggesting this, hence
> my questions to the FreeType list.
> 
> You previously said:
>> The x position of the top pen position in the vertical writing mode can
> be calculated by (advance / 2) - bearingX, both can be obtained from hmtx
> table.
> 
> Is bearingX the left side bearing? I'm not seeing why this would be
> subtracted from the AdvanceWidth/2 . It seems that a glyph would typically
> be centered between the horizontal origin and the horizontal origin plus
> the advance width.
> 
> Looking at a typical character in a Japanese font file I have, I see:
> 
> xMin = 143
> 
> xMax = 1907
> 
> AdvanceWidth = 2048 (1 em)
> 
> This makes the left side bearing 143 and the right side bearing 141. The
> character is almost centered in the advance width, so I'd expect the
> vertical origin to be somewhere around 1024 (centered above the
> character).
> 
> On the comma position variation between vertical and horizontal text, I
> guess that is typically handled by the glyph substitution table. Existing
> cinema subtitle rendering systems do not seem to make use of that table.
> 
> THANKS for all the information! I really appreciate your help in my
> understanding how this works. I will have a look at the documents you
> referenced.
> 
> Harold
> 
> 
> 
> 
> 
>> Dear Mr. Hallikainen,
>> On 2021/05/15 4:47, Harold Hallikainen wrote:
>>> I am trying to understand how font files are used when writing
>>> vertically
>>> (such as for Japanese text). I'm pretty new to this, so please excuse
> my ignorance.
>> Thanks, but I suggest, please do not try to understand it completely by
> FreeType document. The modern applications trying to support the CJK
> vertical writing mode use more complicated frameworks, like HarfBuzz. The
> support of CJK vertical writing mode in FreeType is very fundamental
> level. No line breaking, no auto-rotation, etc etc.
>>> https://www.freetype.org/freetype2/docs/glyphs/glyphs-3.html shows the
> horizontal and vertical baselines for horizontal and vertical text. I
> THINK the glyph "drawing instructions" are relative to the horizontal
> origin. When writing horizontally, the horizontal origin of a character is
>>> placed at the pen position passed into the renderer, and the glyph is
> drawn with reference to that position. The next character starts with its
>>> pen position at the old pen position plus the AdvanceWidth.
>>> For vertical text, it looks like there is a vertical origin that is
> typically centered above the glyph. The Y offset from the horizontal
> origin is either in the VORG table or can be calculated from yMax and the
>>> top side bearing. It is very unclear to me how one determines the X
> offset
>>> from the horizontal origin to the vertical origin. Is there a drawing
> or something that shows how this is done? When rendering vertical text, I
> assume the renderer is passed a pen position for the top character. The
> renderer then applies the offset to get to the horizontal origin and draws
>>> the glyph based on the horizontal origin (just as for horizontal text).
> Is
>>> this anything close to correct?
>> The x position of the top pen position in the vertical writing mode can
> be calculated by (advance / 2) - bearingX, both can be obtained from hmtx
> table.
>> The y position of the top pen position in the vertical writing mode,
> measured in the glyph-internal coordinate system, can be calculated by
> yMax + bearingY. The bearingY can be obtained from vmtx table. The yMax
> can be obtained from the glyph instructions.
>> Each glyph instruction in the glyf table has its header, which provides
> the glyph bounding information, xMin, yMin, xMax, yMax.
>>> Character positions in a cell change depending on whether the character
> is
>>> in a horizontal or vertical string. For example, in Japanese, the comma
> in
>>> horizontal text is low and to the left (so it "hugs" the previous
> word).
>> Such features are now regarded as a part of the line breaking features,
> it is the task of the text layout system in the higher layer,
>> not the task of the FreeType rendering a glyph image from a font file.
> Please take a look on Unicode Standard Annex #50 (to figure the
>> terminology),
>> JLReq (https://www.w3.org/TR/jlreq/ to see the tons of the conventions
> which Japanese experts hope). They are totally too much to put in
> FreeType.
>>> In vertical text, it is high and to the right (so it, again, "hugs" the
> previous word since text reads top to bottom and columns right to
> left). It sees that this difference could be handled by changing the
> offset between the horizontal and vertical position. It could also be
> handled through glyph substitution. It could also be handled through the
> use of a
>>> separate Unicode code point (for example, U+3001 for horizontal text
> and U+FE11 for vertical text).
>> Using or avoiding the compatibility characters in Unicode is highly
> dependent with the (computational) cultural region. These vertical glyphs
> in the compatibility characters were introduced for legacy
> character encodings in PRC or Taiwan, not those in Japan. Japanese
> industrial character sets do not separate the codepoints for the glyph for
> the horizontal and vertical writing mode, so most plain texts
> produced by the software customized for Japanese market do not include
> U+FE11, at least, most users are not trained how to input them.
>> Hope if I could answer some of your questions.
>> Regards,
>> mpsuzuki
> 
>