[mpeg-OTspec] Toward a Composite Font format specification

[Ken Lunde]

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’d 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,
>>>
>>> ― 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
>>
>>
>>
>