[mpeg-OTspec] Toward a Composite Font format specification

[Ken Lunde]

Mikhail,

I appreciate the clarification, and I am okay with the suggestion to  
make this attribute opaque.

Regards...

-- Ken

On 2009/08/31, at 11:34, Mikhail Leonov wrote:

> Hi Ken,
> Even embedded fonts can have paths, depending on the specific  
> document format. For example, it's not uncommon to have virtual  
> resource directories inside a document. This is why I believe we  
> should simply have an opaque string property that lets one encode  
> the location according to the target environment specifics.
>
> Thanks,
> Mikhail Leonov
> Microsoft
>
> -----Original Message-----
> From: mpeg-OTspec at yahoogroups.com [mailto:mpeg- 
> OTspec at yahoogroups.com] On Behalf Of Ken Lunde
> Sent: Saturday, August 29, 2009 7: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
>
>
>
>