Fwd: [Freetype] Font files and vertical text

[suzuki toshiya]

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.



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