[mpeg-OTspec] Toward a Composite Font format specification

[Ken Lunde]

Vladimir,

My main fear in this is that we'd be asking consumers to do something  
that they are already doing, or overriding it. Some consumers may lack  
the ability to override the behavior that dictates whether a device or  
embedded (or web) font is used.

Ultimately, each consumer will need to decide whether it can honor the  
intent of the Composite Font recipe.

Regards...

-- Ken

On 2009/08/31, at 12:17, Levantovsky, Vladimir wrote:

> 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
>>
>>
>>