[mpeg-OTspec] Toward a Composite Font format specification

[Mikhail Leonov]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090826/d1d7e972/attachment.html>