[mpeg-OTspec] Toward a Composite Font format specification
Karsten Luecke
karstenluecke at yahoo.de
Fri Sep 4 10:26:47 CEST 2009
Wrote but forgot to send it ...
A transformation matrix is a very good idea.
(This is also nice in that it introduces something to glyf-based OTFs
that I missed so far -- or does it exist and I only didn't notice?)
> Perhaps we should apply a transformation matrix to the
> glyph, and a separate x/y scaling to the metrics.
Do I understand it correctly that the transformation matrix would not
affect metrics? If so, then this needs to be made very explicit in the
spec, to make sure that a designer/producer cares that matrix and
scaling are in tune.
Best wishes,
Karsten
Daniel Strebe wrote:
> Karsten & colleagues,
>
> In order to achieve the effect of magnifying the glyph without affecting
> the associated metrics, one would need to apply Karsten’s proposed
> tracking on both sides of the glyph. That’s feasible, but it makes me
> worry about how the font machinery ends up reporting metrics to the
> client and how the client interprets those metrics. Something reported
> to the client as tracking will cause behavioral changes in the client
> that are specific to the client, particularly at line starts and ends
> and in distribution of excess whitespace.
>
> As I consider this proposed magnification, I realize it would be better
> to have a full linear transformation matrix that may be applied
> uniformly to a component font. This allows for 斜体 (shatai), the
> technique in phototypesetting of interposing a lens, generally tilted
> with respect to the beam, between the projector and the film. This is
> fairly common in CJK layout and also has precedence in Western
> typography. It can approximate italicization or effectively change slant
> angle in order to better match component fonts. In this case there is no
> longer any specific notion of “center-based”; the entire glyph gets
> magnified, sheared, translated, and rotated in one operation as referred
> to the glyph origin. For center-based typography, the adjustment would
> be made in the translation component of the matrix.
>
> Until now we have considered scaling with metrics, and magnification
> independent of metrics. Perhaps we should break the problem apart
> differently. Perhaps we should apply a transformation matrix to the
> glyph, and a separate x/y scaling to the metrics. In this way we can
> eliminate any conflict, confusion, or compounding of scaling of the
> glyph itself, provide for all cases considered, and avoid special cases
> for ideographic fonts.
>
> Regards,
>
> ― daan Strebe
> Senior Computer Scientist
> Adobe Systems Incorporated
>
>
> On 09/08/26 3:11, "Karsten Luecke" <karstenluecke at yahoo.de> wrote:
>
>
>
>
>
> So as I understand Mr Strebe's and Mr Lunde's descriptions, there
> should be:
> -- ScaleFactorX/ScaleFactorY
> (scaling everying including all metrics)
> -- CompressFactorX/CompressFactorY
> (compressing outlines but no other metrics)
> I would then omit uniform counterparts ScaleFactor and CompressFactor
> since the same can be expressed with -X and -Y ones.
>
> However, I wonder if the latter is not too CJK-specific. As far as I
> see, the effect of CompressFactorX can be achieved as well by
> ScaleFactorX + tracking, and CompressFactorY by ScaleFactorY + leading.
> Because IF CompressFactorX/CompressFactorY is available, why not also
> use CompressFactorX/CompressFactorY in combination with
> ScaleFactorX/ScaleFactorY with Latin script fonts, to achieve a tracking
> effect. This however might have odd effects on mark positioning: Imagine
> that CompressFactorX "scales" a glyph with respect to its center while
> not adjusting its width, but since this does not affect other metrics
> like mark attachment points defined in GPOS, the mark position will
> be off.
>
> Weren't it easier to introduce an additional TrackingX factor so that
> via ScaleFactorX plus TrackingX you achieve the desired effect of
> CompressFactorX? And via ScaleFactorY plus BaselineAdjustment you
> achieve the desired effect of CompressFactorY?
>
> This just "for consideration". I have not thought through it in detail.
>
> Best wishes,
> Karsten
>
> Ken Lunde wrote:
> > daan,
> >
> > I consider InDesign's Composite Font functionality to be near or at
> > the high end of the typographic spectrum, in terms of such
> typographic
> > attributes, so if these attributes in this Composite Font
> > specification are equivalent to what InDesign supports, I think it
> is
> > safe to assume that we're in a good position.
> >
> > Like you, I'd like to know if anyone else has any additional details
> > that could help with this discussion.
> >
> > Regards...
> >
> > -- Ken
> >
> > On 2009/08/25, at 17:08, Daniel Strebe wrote:
> >
> > > Thanks, Ken.
> > >
> > > Anyone else? Any conceivable use case for square advance widths
> in a
> > > non-square design space?
> > >
> > > I don’t like to advocate limiting what people can do. Still,
> > > everything we allow in manipulating component fonts costs
> > > engineering and testing time in clients, discouraging their
> interest
> > > in implementing the facility. Without examples of such fonts or
> even
> > > use cases for such fonts, I’m leery of incorporating the
> > > functionality. Also, I think a uniform magnification pared with
> > > independently specifiable x/y scalings might perhaps help people
> > > keep the semantics distinct in their own minds when creating recipes.
> > >
> > > I do not think my arguments carry much weight; if anyone could come
> > > up with a hypothetical reason someone might need asymmetric
> > > magnification then I would favor adding semantics for it in the
> > > grammar.
> > >
> > > Regards,
> > >
> > > ― daan Strebe
> > > Senior Computer Scientist
> > > Adobe Systems Incorporated
> > >
> > >
> > > On 09/08/25 14:57, "Ken Lunde" <lunde at adobe.com
> <mailto:lunde%40adobe.com> > wrote:
> > >
> > > daan,
> > >
> > > There are non-square designs, but their horizontal and vertical
> > > advances match the extent to which they are non-square. In other
> > > words, their horizontal and vertical advances are uniform, but
> not the
> > > same for both axes.
> > >
> > > Newspaper fonts in Japan are compressed along the Y-axis. Those in
> > > China, because horizontal is the official writing direction, are
> > > compressed along the X-axis. AXIS, a type foundry in Japan, released
> > > condensed and compressed versions of their AXIS family, which have
> > > compression done along the X-axis. This allows more glyphs to fit
> into
> > > a fixed area, and seems very suited for use on mobile devices.
> > >
> > > Anyway, what I have described are fonts that have been designed using
> > > a non-square design space.
> > >
> > > Regards...
> > >
> > > -- Ken
> > >
> > > On 2009/08/25, at 14:44, Daniel Strebe wrote:
> > >
> > >> Mikhail,
> > >>
> > >> Thanks for the comment.
> > >>
> > >> I am uncertain about the need for independent x/y
> > >> “magnification”. You correctly note that you cannot
> > >> achieve “everything” with just uniform magnification
> > >> combined with x/y scaling. And, like you, I cannot come up with a
> > >> scenario that requires it.
> > >>
> > >> For the font experts at large: Do we know of any CJK fonts that use
> > >> a square character advance (that is, same advance horizontally as
> > >> vertically) but whose effective ideographic M-box is rectangular?
> > >> (That is, the “average” glyph impression is
> > >> significantly not-square.) Can we see any reason why anyone would
> > >> ever create such a thing? Without a font constructed like this, I do
> > >> not see any point in non-uniform magnification, since there would
> > >> never be anything to adjust for.
> > >>
> > >> Regards,
> > >> ― daan Strebe
> > >>
> > >>
> > >> On 09/08/25 13:12, "Mikhail Leonov" <mleonov at microsoft.com
> <mailto:mleonov%40microsoft.com> > wrote:
> > >>
> > >> Daan,
> > >> I agree, these properties need to have distinct names that emphasize
> > >> the difference in how metrics are scaled, as opposed to how scale
> > >> factors are specified.
> > >>
> > >> In addition, should glyph magnification property have separate X and
> > >> Y scale factors as well? I don’t have concrete scenarios in
> > >> mind that would use this feature yet, but it makes sense in terms of
> > >> symmetry.
> > >>
> > >> Best regards,
> > >> Mikhail Leonov
> > >> Microsoft
> > >>
> > >>
> > >> From: mpeg-OTspec at yahoogroups.com
> <mailto:mpeg-OTspec%40yahoogroups.com> [mailto:mpeg-
> > >> OTspec at yahoogroups.com <mailto:OTspec%40yahoogroups.com> ] On
> Behalf Of Daniel Strebe
> > >> Sent: Friday, August 21, 2009 5:04 PM
> > >> To: Ken Lunde; mpeg-OTspec at yahoogroups.com
> <mailto:mpeg-OTspec%40yahoogroups.com>
> > >> Subject: Re: [mpeg-OTspec] Toward a Composite Font format
> > >> specification
> > >>
> > >>
> > >>
> > >>
> > >> Colleagues,
> > >>
> > >> As I explained in my earlier message found at the bottom of this e-
> > >> mail, the two kinds of scaling are independent and mutually
> > >> compatible operations. Both are necessary simultaneously for a good
> > >> recipe in some situations.
> > >>
> > >> ScaleFactorX/ScaleFactorY use the baseline as an anchor and scale
> > >> everything concerning the glyph, including the outline, kerning,
> > >> escapements, and advance.
> > >>
> > >> Uniform scaling, on the other hand, scales from the center of the
> > >> ideographic box, and does not affect anything but the glyph
> > >> impression. Most importantly, it does not affect horizontal or
> > >> vertical advance.
> > >>
> > >> Both kinds of scaling are needed simultaneously when adjusting
> > >> component fonts of an ideographic script when the component fonts
> > >> contain ideographic boxes of differing aspect ratios and
> > >> differing “color”. Color refers to the foreground/
> > >> background ratio of a glyph as determined by of amount of the
> > >> advance width that the average glyph consumes, and the design weight
> > >> of the typeface.
> > >>
> > >> They should be given distinct names to distinguish the semantics.
> > >> Perhaps:
> > >>
> > >> Glyph magnification, in place of “uniform scaling”
> > >> Character scaling, to refer to ScaleFactorX/ScaleFactorY
> > >>
> > >> Regards,
> > >>
> > >> ― daan Strebe
> > >> Senior Computer Scientist
> > >> Adobe Systems Incorporated
> > >>
> > >>
> > >> On 09/08/21 13:59, "Ken Lunde" <lunde at adobe.com
> <mailto:lunde%40adobe.com> > wrote:
> > >>
> > >>
> > >> Mikhail,
> > >>
> > >> While I cannot answer for daan, I have observed that InDesign's
> > >> Composite Font dialog allows all three to be applied independent of
> > >> one another. My gut feeling is that their use should be mutually
> > >> exclusive, meaning ScaleFactor to be applied to both axes, or
> > >> ScaleFactorX+ScaleFactorY as a pair to be set independent of one
> > >> another. Perhaps daan can describe a usage scenario in which both
> > >> forms of scaling are required.
> > >>
> > >> I would think that any use of both forms of scaling could also be
> > >> adequately described in terms of only ScaleFactorX+ScaleFactorY as a
> > >> pair.
> > >>
> > >> Regards...
> > >>
> > >> -- Ken
> > >>
> > >> On 2009/08/21, at 13:53, Mikhail Leonov wrote:
> > >>
> > >>> Ken and Daan,
> > >>> Do you think ScaleFactorX+ScaleFactorY pair and ScaleFactor should
> > >>> be mutually exclusive, or are there examples where using both
> > > forms
> > >>> of scaling in the same entry provides value to the recipe creator?
> > >>>
> > >>> Mikhail Leonov
> > >>> Microsoft
> > >>>
> > >>> -----Original Message-----
> > >>> From: mpeg-OTspec at yahoogroups.com
> <mailto:mpeg-OTspec%40yahoogroups.com>
> <mailto:mpeg-OTspec%40yahoogroups.com
> > >>> [mailto:mpeg-
> > >>> OTspec at yahoogroups.com <mailto:OTspec%40yahoogroups.com>
> <mailto:OTspec%40yahoogroups.com> ] On
> > >> Behalf Of Ken Lunde
> > >>> Sent: Friday, August 14, 2009 6:07 PM
> > >>> To: mpeg-OTspec at yahoogroups.com
> <mailto:mpeg-OTspec%40yahoogroups.com>
> <mailto:mpeg-OTspec%40yahoogroups.com
> > >>>
> > >>> Subject: Re: [mpeg-OTspec] Toward a Composite Font format
> > >>> specification
> > >>>
> > >>> daan,
> > >>>
> > >>> Thank you. This is exactly the sort of use-scenario description
> > > that
> > >>> I was hoping to elicit with my post.
> > >>>
> > >>> Two additional <ComponentFont> attributes should be added:
> > >>>
> > >>> ScaleFactorX
> > >>> ScaleFactorY
> > >>>
> > >>> Regards...
> > >>>
> > >>> -- Ken
> > >>>
> > >>> On 2009/08/14, at 15:58, Daniel Strebe wrote:
> > >>>
> > >>>> Ken,
> > >>>>
> > >>>> Thanks for wading into this.
> > >>>>
> > >>>> I think we should look at Adobe InDesign's scaling in more
> > > detail.
> > >>>> What InDesign provides relevant to this discussion is:
> > >>>>
> > >>>> * Adjust baseline of a component font.
> > >>>> * Scale glyphs in a component font horizontally.
> > >>>> * Scale glyphs in a component font vertically.
> > >>>> * Scale glyphs in a component font uniformly with respect to
> > >> the
> > >>>> glyph's center while preserving its width.
> > >>>>
> > >>>> You cannot fully replicate both semantics by dropping any of the
> > >>>> three
> > >>>> provisions. The purpose of (2) and (3) is to adjust a component
> > >> font
> > >>>> whose glyphs normally run along some baseline, such as Latin-
> > > script
> > >>>> or
> > >>>> Indic-script fonts. The adjustment applies to the glyph outline
> > > as
> > >>>> well as its horizontal and vertical advance. The purpose of (4)
> > >> is to
> > >>>> adjust a component font whose glyphs run along a center line,
> > >> such as
> > >>>> Chinese ideographs. The adjustment applies to the glyph outline
> > > but
> > >>>> not its horizontal or vertical advance.
> > >>>>
> > >>>> To elaborate, in Latin-script composite fonts, it is common to
> > >> scale
> > >>>> glyphs of a component font horizontally, and this scaling
> > > typically
> > >>>> applies to all behavior of the font: the amount of horizontal
> > > space
> > >>>> the glyph takes up, kerning amounts, escapements. In ideographic
> > >>>> fonts, normally ideographs are considered fixed-width for
> > >> typographic
> > >>>> purposes, and you do not want mixed widths regardless of which
> > >>>> component fonts the glyphs came from. Yet meanwhile you must
> > >> balance
> > >>>> the space of the ideographs for two or more different source
> > > fonts,
> > >>>> each of which has a different idea of "color" for the font.
> > >>>> (Color, meaning, the amount of whitespace consumed by the
> > > "average"
> > >>>> glyph in the ideographic repertoire.) Therefore you scale from
> > > the
> > >>>> center of the ideographic box but leave the metrics alone.
> > >>>>
> > >>>> The reason InDesign allows both forms of scaling is because (4)
> > > may
> > >>>> be
> > >>>> required to balance the color, while (2) and/or (3) may be
> > > required
> > >>>> to
> > >>>> adjust for a non-square construction of the fixed-width
> > > ideographic
> > >>>> glyphs. While square in most fonts, especially in the past, some
> > >> are
> > >>>> not, and this practice is increasing. Hence, it is not so exotic
> > >>>> for a
> > >>>> well-constructed composite font to require all of (1), (2), (3),
> > >> and
> > >>>> (4).
> > >>>>
> > >>>> Regards,
> > >>>>
> > >>>> - daan Strebe
> > >>>> Senior Computer Scientist
> > >>>> Adobe Systems Incorporated
> > >>
> > >> .
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
>
>
>
>
>
More information about the mpeg-otspec
mailing list