Re: Font-face Descriptors for Matching

On Aug 6,  4:38pm, Clive Bruton wrote:

> Chris Lilley wrote at 6/8/97 3:46 pm

> >On Aug 5,  2:50pm, Clive Bruton wrote:
> >> (I therefore wasn't surprised to see Adobe staff on the authors list).
> >> Can I assume that these descriptors are to be interpreted by ATM, using
> >> the Adobe Sans/Serif Multiple Masters as their base?
> >
> >They could be. They are not tied to a particular technology. ATM is not
> >required. Applications that used ATM to do the synthesis would be a
> >good idea, though.
>
> Sure, since the technology is in place, widely available, and already
> does the job.

On the platrorms it is available for and for people who have obtained a
copy, yes. It still isn't a required piece of technology, though.

> >We don't have much support for script fonts as a specific type, true.
> >They can be indicated by setting the first number in the panose-1
> >descriptor to 3...
>
> (Chris indicates such flags are available in other forms)
>
>
> Ok, what I'm suggesting is that you allow for the full set of Acrobat
> font descriptors (independent of Panose) since the standard is widely in
> use, and this would help content creators develop for different media by
> using the same data (ie they can use the same font synthesis settings in
> Acrobat/ATM as HTML).

That strikes me as bogus. It would result in duplication of information.
If there is an important descriptor missing, then sure, tell me about it.
If the descriptor is there but happens not to use the same name as your
favoured piece of technology that might be used to help implement it, I
don't see a case. Provided the description in the spec is clear, the
required font descriptor can readilly be written by any authoring
software. It can then be transmitted over the web and used by multiple
readers all using different synthesis engines, download strategies, and
intelligent matching options.

> This also enables browser vendors to make simple
> calls to system extensions, rather than having to reinvent the wheel (and
> have even more disk/memory demand from browsers).

Don't follow. Perhaps an example would help.

> I am working on a project for a font vendor to have the Acrobat font
> descriptors included within their fonts (they cannot currently be
> accurately derived from the font). If this were to become widespread then
> it would also help in font synthesis for end users and content providers
> in that the data could easily be derived from such fonts, ensuring,
> again, consistency of synthesis across different media.

Excellent news. Font vendors should be encouraged to provide as much
metadata about their fonts as possible.

> By all means include alternative methods of font synthesis, but can we
> have *full* implentations of all rather than borrowing from each other.

I think you misunderstand. This is not the "how to use Super ATM 4.0(tm)
on the Web" draft. It's the "how to use Fonts on the Web" draft. It
doesn't include any _methods_ of font synthesis. It includes data that
can be used for matching and for synthesis.

-- 
Chris Lilley, W3C                          [ http://www.w3.org/ ]
Graphics and Fonts Guy            The World Wide Web Consortium
http://www.w3.org/people/chris/              INRIA,  Projet W3C
chris@w3.org                       2004 Rt des Lucioles / BP 93
+33 (0)4 93 65 79 87       06902 Sophia Antipolis Cedex, France

Received on Wednesday, 6 August 1997 12:31:36 UTC