[mpeg-OTspec] Toward a Composite Font format specification

[Levantovsky, Vladimir]

Ken,

I agree that existing implementations already deal with the scenarios
where fonts may be present locally and/or embedded, and that consumers
who support embedded fonts may behave differently with regard to giving
preferences to embedded vs. local fonts. I see this uncertainty in
consumer behavior as a potential interoperability problem. 

It is true that embedded fonts are most likely to be used when a
producer cares about content presentation and appearance, and this is
when the attribute about font location is likely to be present. I think
it would be seen as a benefit to give producers a certain level of
assurance of consumer's behavior. In fact, I know that in some
environments this has already been done. For example, in Java MIDP3.0
profile - if there is an apparent conflict between embedded and local
font (e.g. both fonts have the same names), the embedded (or downloaded)
font is always given a preference to make sure that the content is
rendered using a resource chosen by producer (author).

In general, I believe that we should try (whenever possible) to reduce
potential uncertainty in consumer behavior, especially if a feature
under consideration (e.g. a preference between embedded and local font)
is not going to affect implementation complexity and cost. A good
specification should have a healthy balance between mandatory and
optional features - a specification that is overly strict may be seen as
burden for implementers, but, alternatively, a specification where
everything is optional (MMS come to mind) will likely result in
producing incompatible implementations.

Regards,
Vladimir


> -----Original Message-----
> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com]
> On Behalf Of Ken Lunde
> Sent: Saturday, August 29, 2009 10:32 AM
> To: mpeg-OTspec at yahoogroups.com
> Subject: Re: [mpeg-OTspec] Toward a Composite Font format
specification
> 
> Vladimir,
> 
> In thinking about the issue that you raised, I don't think that we
> need to worry about the case when a font with the same name exists on
> the device and also embedded in the file. Consider the fact that
> consumers who support embedded fonts already need to deal with this
> scenario, and obviously prefer one over the other. So, if this
> attribute specifies one or the other (device versus embedded), that is
> sufficient to guide the consumer. And, there are some consumers that
> are unable to support files with embedded fonts. Likewise, some
closed-
> environment consumers may even be unable to support device fonts,
> though there will be very few of these in the real world.
> 
> In any case, if the producer cares about font location (device,
> embedded, or web), what this attribute constitutes is a preference. If
> it is flagged as a device font, a path to the font may be included as
> part of this attribute. If it is flagged as embedded, it is treated as
> a boolean, because it is a binary condition.
> 
> My reasoning is that producers would be asking consumers to do
> something that they already support, or already have a strong
> preference one way or another, and also that producers may be
> specifying information that a consumer would be forced to ignore.
> 
> Feel free to prove me wrong about this issue.
> 
> -- Ken
> 
> On 2009/08/28, at 14:02, Levantovsky, Vladimir wrote:
> 
> > Ken,
> >
> > I like your proposed approach, and I agree that issues such as
> > rendering and font access permissions should be left out of
> > composite font recipe. With regards to font location, one additional
> > case that we should consider and clarify is if the font is embedded
> > in a document (or in a CF recipe) and is also present on a device. I
> > believe that some implementations in these circumstances may
> > sometime disregard the embedded font and use local copy instead,
> > although I can imagine there may be circumstances when authors may
> > want the embedded font be used at all times, regardless of whether
> > the same font is present on a device (e.g. if embedded font contains
> > additional character set that may not be part of the local font).
> >
> > Regards,
> > Vladimir
> >
> >
> >> -----Original Message-----
> >> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-
> >> OTspec at yahoogroups.com]
> >> On Behalf Of Ken Lunde
> >> Sent: Friday, August 28, 2009 4:41 PM
> >> To: mpeg-OTspec at yahoogroups.com
> >> Subject: Re: [mpeg-OTspec] Toward a Composite Font format
> >> specification
> >>
> >> Mikhail and others,
> >>
> >> Sorry for the delay. I was discussing this issue internally with a
> >> couple different development teams. I wanted to make sure that our
> >> bases are covered before I suggested some working definitions.
> >>
> >> I like the idea of using "LocationHint" as the name of this
> >> <ComponentFont> attribute.
> >>
> >> Getting back to the issue, I think that there are three of them to
> >> consider:
> >>
> >> 1) Font location. Installed onto the device proper, meaning in a
> >> standard location, embedded in the file that references it, either
> >> directly or via a Composite Font recipe, or elsewhere (web fonts).
> >>
> >> 2) Rendering. Done by the OS, the application itself, or some other
> >> rendering client such as a library.
> >>
> >> 3) Access. This boils down to private versus public. In general, if
> a
> >> font is embedded in the file that references it, it is effectively
> >> private, and available only to the consumer. If a font is installed
> >> on
> >> the device in a standard location, it is effectively public,
> multiple
> >> consumers have access to it, and can thus use it.
> >>
> >> In the context of Composite Fonts, and considering producers (those
> >> who create the Composite Font recipes) and consumers (those who use
> >> or
> >> "consume" the Composite Font recipes), I cannot think of any usage
> >> scenarios that specify how rendering is to be done. So, Issue #2
> >> becomes moot. The consumer already knows how to handle this, and
> >> simply knowing where to look for the font is sufficient.
> >>
> >> And, Issue #3 is a non-issue in the sense that the location of the
> >> font implies its access level.
> >>
> >> Thus, what we have left is Issue #1, which is about location.
> >> Embedded
> >> fonts do not need a location, but need a name (this is required
> >> anyway
> >> for any Component Font), and it may be useful to flag it as an
> >> embedded font. Device fonts can benefit from a location, such as a
> >> path, and the usage scenario you gave helps. I assume that web
fonts
> >> merely require a URL.
> >>
> >> The following are three definitions to consider:
> >>
> >> Device font:
> >>   A font installed on the device, in a standard location, and thus
> >> accessible by multiple consumers.
> >>
> >> Embedded font:
> >>   A font or subset of a font that is embedded in a file that
> >> references it, and thus accessible only by the file's consumer.
> >>
> >> Web font:
> >>   A font that is neither installed on the device nor embedded in a
> >> file, but is otherwise accessible through the network.
> >>
> >> Thoughts?
> >>
> >> -- Ken
> >>
> >> On 2009/08/26, at 15:52, Mikhail Leonov wrote:
> >>
> >>> Hi Ken,
> >>> This type of issue came up in some of my recent conversations as
> >> well.
> >>>
> >>> Conceptually, recipe creators want to specify some additional
> >>> properties about a component font, such as its location. For some
> >>> scenarios a simple Boolean flag is sufficient, while for other
> >>> scenarios something like a URL or an internal resource path is
> >>> necessary.
> >>>
> >>> To give an example of the latter, a document could embed 2
versions
> >>> of the same font and use different resource paths, for example /
> >>> Resources/Fonts/1/arial.ttf and /Resources/Fonts/2/arial.ttf.
> >>>
> >>> Given there is a large number of potential methods for storing
font
> >>> file locations, I(tm)fd like to suggest for this property to be
opaque
> >>> and optional, akin to a hint rather than a strict directive.
> >>>
> >>> How does a new string property LocationHint sound?
> >>>
> >>> Thanks!
> >>> Mikhail Leonov
> >>> Microsoft
> >>>
> >>>
> >>> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-
> >>> OTspec at yahoogroups.com] On Behalf Of Ken Lunde
> >>> Sent: Wednesday, August 26, 2009 2:26 PM
> >>> To: mpeg-OTspec at yahoogroups.com
> >>> Subject: Re: [mpeg-OTspec] Toward a Composite Font format
> >>> specification
> >>>
> >>>
> >>>
> >>> All,
> >>>
> >>> Slight topic deviation ahead...
> >>>
> >>> I was in a meeting this morning, and its discussions led to an
idea
> >>> for another <ComponentFont> attribute that we have not yet
> >> considered.
> >>> Under some circumstances, especially when dealing with embedded
> >> fonts,
> >>> it may be useful to specify whether the font is embedded (in a
file
> >>> that references the Composite Font or the Component Font) or
> >> available
> >>> on the device (a "device" font). This, of course, would be
> optional,
> >>> but I guarantee that some producers will want to specify this.
> >>>
> >>> I am not sure about the best way to characterize this, in terms of
> >>> an
> >>> attribute name, but perhaps we can state that all <ComponentFont>
> >>> instances are "device fonts" unless an "IsEmbedded" boolean flag
is
> >>> specified.
> >>>
> >>> I would welcome any thoughts about this.
> >>>
> >>> -- Ken
> >>>
> >>> On 2009/08/26, at 12:20, Thomas Phinney wrote:
> >>>
> >>>> My first assumption would be that all scaling should include
> >>>> scaling
> >>>> metrics, though I am mindful of the issues Karsten brings up.
> >>>>
> >>>> T
> >>>>
> >>>> On Wed, Aug 26, 2009 at 9:27 AM, Daniel
> >> Strebe<dstrebe at adobe.com<mailto:dstrebe%40adobe.com
> >>>>>>
> >>>> wrote:
> >>>>>
> >>>>> Thomas,
> >>>>>
> >>>>> Thanks for chiming in. To clarify, do you mean to advocate
> scaling
> >>>>> horizontally within the same design space when you mention faux
> >>>>> small caps?
> >>>>> (Meaning, without increasing the glyph advance width,
escapement,
> >>>>> and
> >>>>> kerning values?)
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> (tm)\ daan Strebe
> >>>>> Senior Computer Scientist
> >>>>> Adobe Systems Incorporated
> >>>>>
> >>>>>
> >>>>> On 09/08/25 21:51, "Thomas Phinney"
> >> <tphinney at cal.berkeley.edu<mailto:tphinney%40cal.berkeley.edu
> >>>>>>>
> >>>>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> I'd advocate keeping the three different scaling factors
> (overall,
> >> X
> >>>>> and Y). I can honestly imagine plenty of use cases for them,
both
> >> in
> >>>>> traditional and non-traditional cases.
> >>>>>
> >>>>> One use for asymmetric X/Y scaling is in manufacturing small
> caps.
> >>>>> One
> >>>>> could use a composite font mechanism to build faux small caps,
> >>>>> possibly scaled slightly so as to be slightly wider than
strictly
> >>>>> proportional scaling. Ditto for creating numeric (or alphabetic)
> >>>>> inferiors or superiors. Using the composite font mechanism would
> >>>>> allow
> >>>>> for taking the base glyphs from a heavier weight of the "same"
> >>>>> typeface....
> >>>>>
> >>>>> cheers,
> >>>>>
> >>>>> T
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> "Men occasionally stumble over the truth, but most of them pick
> >>>> themselves up
> >>>> and hurry off as if nothing ever happened."
> >>>> - Sir Winston Churchill
> >>>>
> >>>>
> >>>> ------------------------------------
> >>>>
> >>>> Yahoo! Groups Links
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> ------------------------------------
> >>
> >> Yahoo! Groups Links
> >>
> >>
> >>
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>