[mpeg-OTspec] Toward a Composite Font format specification

[Ken Lunde]

Mikhail,

I will be out of the office for the first week of October (hunting  
pronghorn antelope in Wyoming), so let's plan to focus on a draft  
format specification during the last ten days of September.

Regards...

-- Ken

On 2009/09/03, at 15:44, Mikhail Leonov wrote:

>
> Hi Daan,
>
> I support the idea of allowing a full glyph transformation matrix to  
> be specified. This will provide a general solution without the need  
> to introduce additional values in the future.
>
>
>
> Just to let everyone know, I will be on vacation starting tomorrow  
> until September 19th. When I get back, I plan to work closely with  
> the ad hoc group on making sure there is a draft format  
> specification in time for the next MPEG meeting in October.
>
>
>
> Best regards,
>
> Mikhail Leonov
>
> Microsoft
>
>
>
> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg- 
> OTspec at yahoogroups.com] On Behalf Of Daniel Strebe
> Sent: Monday, August 31, 2009 12:38 PM
> To: Karsten Luecke; mpeg-OTspec at yahoogroups.com
> Subject: Re: [mpeg-OTspec] Toward a Composite Font format  
> specification
>
>
>
>
>
>
> Karsten & colleagues,
>
> In order to achi! eve 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 l! ayout 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
> A! dobe Systems Incorporated
>
>
> On 09/08/26 3:11, "K! arsten L uecke" <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/ScaleFa! ctorY 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
> > spe! cificati on 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
> >&g! t; 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 the! ir horizontal and vertical
> >> advances match the exte! nt to wh ich 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 c! omment.
> >>>
> >>> 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.
> >>>
> >>&g! t; Regar ds,
> >>> ― 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
> >>>
> >>>
> >&! gt;> 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 messag! e found at the bottom of  
> this e-
> >>> mail, the two! kinds o f 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 refer! s 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,
> &g! t;>>
> >>> While I cannot answer for daan, I h! ave obse rved 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 Scal! eFactor  
> 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.
> >>>>>>&g t;>>> 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 ideogra! phic repertoire.) Therefore you scale from
> >> ! the
> & gt;>>>> 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
> >
> >
> >
> >
>
>
>
>
>
>