Re: Font-face Descriptors for Matching
To: "www-style" <email@example.com>
Subject: Re: Font-face Descriptors for Matching
From: Clive Bruton <firstname.lastname@example.org>
Date: Wed, 6 Aug 97 22:27:39 +0100
From email@example.com Wed Aug 6 17: 30:30 1997
X-Authentication-Warning: www10.w3.org: Host [22.214.171.124] claimed to be battersea.indx.co.uk
x-mailer: Claris Emailer 2.0, March 15, 1997
Chris Lilley wrote at 6/8/97 5:23 pm
>On Aug 6, 4:38pm, Clive Bruton wrote:
>> Chris Lilley wrote at 6/8/97 3:46 pm
>> >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.
It's available in one form or another for Unix/Mac/Win, and is free via
an installation of Acrobat Reader. Probably the most widely used font
format (across many platforms) is PostScript Type 1. I also believe that
it is likely that the only "morphable" font format that will be generally
available in the near future is Type 1 Multiple Masters. ATM is a
"required piece of technology" for this font format (at least if you want
to see it on screen).
>> 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.
In what way? I have the information I need for an Acrobat document, why
shouldn't I be able to apply the same info to a HTML document? Surely
duplication would only occur if I had to reformat that data into some
other form with different parameters?
If you mean that in adding the full set of ATM descriptors would overlap
with the Panose info, yes of course that's duplication, but I'm not
suggesting that you use both, one or the other is obviously preferable.
If you think this additional set of descriptors is duplication, then you
had better reconsider the whole draft document, since the various font
descriptors discussed provide for considerable redundancy.
>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.
If I may, I think it *extemely* unlikely that multiple "synthesis
engines" will exist, the incentive to write such, and to freely
distribute, does not exist (especially as Adobe has already done such).
If there were demand for such engines they would already exist (there are
reasons outside of web browsers for the technology), however the only
cross-platform solution currently offered is Type 1 MMs.
I also believe that Adobe and Microsoft's work on OpenType reinforces
>> 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.
Well if ATM already exists, and can render morphable fonts, then it is
much simpler to make a call to a common engine (ATM) than to design your
browser so that it does its own morphing and rendering.
>> 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.
And I'm proposing that you make that as simple as possible by integrating
existing standards, as well as alternatives and new developments, for
real products that actually exist now.
Just as an example, I'm sure that someone could demo a browser utilising
ATM's synthesis within a few weeks (other applications, at least on
MacOS, have used such for a considerable time), another route may take
many months (once the technology matures).
I think you may be opposed to this idea (despite the fact that the
existing draft includes many ATM descriptors) merely because
ATM/PostScript is a proprietory product of Adobe Systems, rather than
some free and open standard. However I believe that competing
technologies are unlikely to develop.
PS I think you'll find that there is no such product as "Super ATM 4.0",
with or without the dreaded trademark symbol.