Re: Font files and vertical text

[Harold Hallikainen]

Thanks you to everyone for the helpful information! Here's a quick summary
of digital cinema subtitle rendering for vertical text.

1. On most systems, the vertical position of the column of text is based
on the top, bottom, or center of the bounding box for the rendered column
of text. I think it SHOULD be based on the vertical origin of the first
character, vertical origin + advance height of the bottom character, or
the center of these two points. When vertical align is top, the difference
between use of the bounding box and the vertical origin would be the top
side bearing of the top character, which is usually small.

2. On most systems, vertical intercharacter spacing is not based on the
advance height but, instead, provides a space (about .06 em) between the
bounding boxes of adjacent glyphs. This results improper rendering of
characters that are not "tall," such as the ichi character and
punctuation. It seems that a system COULD just space the vertical origin
of one character 1 em from the previous vertical origin. All the
characters I have looked at have an advance height of one em.

3. On most systems, the bounding box of each glyph is centered on a
vertical line (at X=Hposition). This results in improper rendering of
asymmetrical glyphs such as punctuation. I originally thought that
different positioning of punctuation between horizontal and vertical text
could be handled by positioning of the vertical origin, but it appears
this is instead handled through glyph substitution.

4. A "compressed" font file is supplied for each "reel" of the film. A
digital cinema movie ("composition") is broken into "reels" with a
separate file for the image, audio, subtitles, and other stuff for
segments of the composition. These segments are called "reels." All the
files are referenced in a Composition Play List that tells the playback
system how to play the composition. The compressed font file includes only
the characters used in that reel. The subtitle file is XML as defined in
SMTPE ST 428-7. It currently leaves several things undefined, such as
intercharacter spacing of vertical text.

5. All digital cinema systems I am familiar with run on some form of Linux.

Again, thanks to all for answering my questions about font files and their
interpretation.

Harold





> 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: mpsuzuki@hiroshima-u.ac.jp
>> Date: Sat, 15 May 2021 19:51:07 +0000
>> From: Harold Hallikainen <harold@mai.hallikainen.org>
>> To: suzuki toshiya <mpsuzuki@hiroshima-u.ac.jp>
>>
>> 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
>>
>>
>


-- 
FCC Rules Updated Daily at http://www.hallikainen.com
Not sent from an iPhone.