[mpeg-OTspec] Toward a Composite Font format specification

[Jeff Engelman]

A few thoughts ...

Target Font - how will this be specified?  Does it need to be on the same 
system -or- can it be on a server / internet  e.g. 
http://ibm.com/fonts/CourierIBM.ttf ? What is the 'unique name' ... Full 
Font Name - file name - WWS - combination of these?   I would like to see 
a way to specify a font that isn't on the current system.  Possibly, 
define a web solution then get W3C to use this iso standard - just so the 
W3C doesn't come up with another mechanism to implement. 

Scaling - we have implemented vertical size and a horizontal scale factor 
(percentage of the vertical) - but we're ok with going with any scheme.

Baseline Shift - we have implemented this function on some of our system 
and we're ok with going with any scheme.

Other parameters such as Unicode Ranges - we haven't done but it's on my 
list.

Language Tag - do we need a method of stating that the language is Complex 
and that layout engines shouldn't try to use other ComponentFonts during 
composition?  Do we intend on allowing Complex Scripts to span 
ComponentFonts?  This could get messy.

Sizing - it would be helpful to be able to specify a different font 
depending on the pointsize requested.  This would help with migration of 
legacy applications. 

I apologize for having more questions than solutions.

Best Regards,
Jeff Engelman
' 720-663-3617
* jeff.engelman at infoprint.com
Ä Typography for the IBM Corporation and InfoPrint Solutions Company, a 
Ricoh | IBM Joint Venture




Ken Lunde <lunde at adobe.com> 
Sent by: mpeg-OTspec at yahoogroups.com
08/14/2009 03:07 PM

To
mpeg-OTspec at yahoogroups.com
cc

Subject
[mpeg-OTspec] Toward a Composite Font format specification






 



All,

In an effort to move the discussions forward, I would like to 
enumerate the primary functional tags, along with my initial ideas 
about what properties or attributes can be specified for each. I have 
already floated these ideas, but now that we're in basic agreement 
about some principles, I am able to condense this into a more readable 
format.

Here we go:

Tag: <ComponentFont>
Attribute: Target (required; a unique name for the font)
Attribute: ScaleFactor (optional; scaling factor, expressed as a 
percentage)
Attribute: BaselineShift (optional; baseline shift, expressed as a 
percentage)

Tag: <Language> (optional)
Attribute: Target (required; an IETF language tag, as specified by 
RFC 4646)

Tag: <Encoding> (optional)
Attribute: Target (required; the Unicode ranges to be used in the 
Composite Font)
Attribute: Original (optional; the encoding ranges in the Component 
Font, if different than the "Target" attribute)

Of course, an appropriate XML namespace will need to be specified.

In looking at the Composite Font feature of Adobe InDesign, there are 
two types of scaling factors, both of which are independent from one 
another, meaning that both can be specified. One is a uniform scaling, 
applying to both the X- and Y-axis. The other is axis-independent 
scaling. While I am all for giving people enough rope to hang 
themselves, I consider this to be comparable to supplying the 
developer with razor-impregnated rope, and strongly suggest that the 
specification allows for only uniform scaling for the "ScaleFactor" 
attribute for the <ComponentFont> tag.

To everyone in this discussions, please think about additional 
attributes for these three functional tags.

Regards...

-- Ken.


_____________________________________________________________________________
"This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." _____________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090902/d36b4c0e/attachment.html>