Re: Anything to discuss during our telcon tomorrow?

On 14/12/2016 21:01, Chris Lilley wrote:
>
>
> On 2016-12-14 15:23, Roderick Sheeter wrote:
>> Cool. Hey, would #postscriptname work for any postscript name? In
>> particular, for accessing a named instance in a variation font?
> Huh, interesting. I hadn't thought about that one!
>
> I think the plan is to access anywhere along an axis by putting the axis
> values on the @font-face descriptors. So named instances are not privileged.

I was going to say it should: named instances should be available by 
name. But there's a complication with that. In principle, you could have 
a collection containing multiple variation fonts, and multiple named 
instances within each of them. Those names might not be unique. So it'd 
be perfectly reasonable (I think) to have:

   MyFamily.ttc
     face: MyFamily-Upright
       instances: Light, Regular, Bold, Black
     face: MyFamily-Italic
       instances: Light, Regular, Bold, Black

as instance names are meaningful only within a single (variation) face.

Therefore, while I think it is useful to provide a means to access named 
instances (without having to discover and specify their actual variation 
coordinates), this needs to be distinct from the use of the PostScript 
name to select a face within a collection.

>
> Would non-variation-aware processors be able to get at named instances?
> (for TrueType glyhs - clearly they would not be able to for CFF2)?
>

I wouldn't expect so. A named instance is just a name for a specific set 
of variation-axis values; but to apply those values, the rasterizer 
needs to know how to process variations.

>>
>> On Wed, Dec 14, 2016 at 11:40 AM, Chris Lilley <chris@w3.org
>> <mailto:chris@w3.org>> wrote:
>>
>>
>>
>>     On 2016-12-13 23:14, Levantovsky, Vladimir wrote:
>>>
>>>     On a related subject – there have been updates on the top-level
>>>     font media type registration. Chris Lilley has been busy at work
>>>     (thank you Chris!) addressing some of the issues reported by the
>>>     IETF-assigned reviewer,
>>>
>>     all of them, I hope :)
>>>
>>>     and the new version of the document has been created as a result.
>>>     Please review and send you comments, if any. The details on the
>>>     document progression can be seen at
>>>      https://datatracker.ietf.org/doc/draft-ietf-justfont-toplevel/
>>>     <https://datatracker.ietf.org/doc/draft-ietf-justfont-toplevel/>
>>>
>>>
>>>
>>
>>     Of note, the most recent couple of drafts have a new fragment
>>     syntax for collections (both font/collection and also font/woff2).
>>     Ken Lunde pointed out that the numeric fragment syntax was
>>     brittle, as new fonts are typically inserted rather than appended
>>     into a collection. Instead, a fragment syntax using the PostScript
>>     name is specified.

There is a downside to using PS names to identify fonts within a 
collection, though: it requires the UA to decode/parse all the faces in 
order to look at their names. The numeric index allows a UA to process 
only the single face that is actually being requested.

JK

>>
>>     This syntax was already in use in CSS3 Fonts, for referring to
>>     locally installed fonts rather than downloaded ones. For use as a
>>     fragment, the only complication is that six characters are allowed
>>     in PostScript names and disallowed in fragment identifiers. They
>>     have to be percent-escaped in the fragments.
>>
>>     An additional benefit is that the syntax is more human readable.
>>     To get at Foo Bold in a collection (or woff2 of a collection)
>>     called bar, the syntax is bar.woff2#Foo-Bold for example, not
>>     bar.woff2#3 or whatever.
>>
>>     As far as I know, no browser or html-to-pdf formatter has support
>>     for collections. So there is no web compat issue. The new syntax
>>     will be more usable, and completes what is needed for us to use
>>     collections in woff2.
>>
>>     --
>>     Chris
>>
>>
>

Received on Wednesday, 14 December 2016 21:51:52 UTC