Re: Font-face Descriptors for Matching

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 
that view.

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


-- Clive

PS I think you'll find that there is no such product as "Super ATM 4.0", 
with or without the dreaded trademark symbol.

Received on Wednesday, 6 August 1997 17:30:30 UTC