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