Re: WebFonts

>From:        lee@sq.com

>More importantly, you don't know the size or resolution of the screen
>that the browser is using.  I have a 150dpi screen on one system, and only
>a 100dpi screen on another.  Our main Macintosh actually has a 75dpi 
>screen!!!
>With such extremes, a bitmap font that can be read easily on one screen
>is utterly useless on another.  And one that is large enough to be
>read easily on most devices -- say, between 20 and 30 pixels per em -- is
>much too large for a 640x480 PC screen, or even an 800x600 portable PC
>or Mac screen.
A good argument. But then if you increase the size of the type on some 
page yourself, you have a problem of the included images being too small.

>> I think that the ratio 
>> of number of read webpages that get printed to the number of unprinted 
>> ones favors the unprinted pages in such a major way that making 
>> complicated and expensive provisions to make webpages printable from the 
>> start is not necessary.
[..]
>Well, Jonathan Hoefler would have saved himself a lot of work, and
>if you agree that Q and K are not used very often, and drop those too,
>you have saved more work.
That is not what I mean. When web pages are mostly seen on screen, they 
should be tuned to the screen. If printing is the most important use of a 
document, then aim for that. If you have something that needs to work 
both on screen and print then you make one with huge compromises to 
layout and design, so it looks bad in both worlds, or you make two 
separate good ones. The technology to print stuff is pretty well 
developed. 
It might be understandable from an engineers point of view to think that 
looking at a page that is meant to be printed _on a screen_ is the same 
as looking at a page on screen that was meant to be seen on screen. This 
is what 10 years of desktop publishing has made use believe, but these 
are not the same activities. The design for screen will become more than 
'a page'

>Note that the TrueDoc system at least -- I'm not sure about the others
>yet, but the Agfa one can probably do this too -- download only the
>outlines (and hints!) for the glyphs you actually use in the document.
>A TrueDoc font is often smaller than the corresponding bitmap font.
I'm sorry I am not entirely familiar with the various proposals for new 
document formats.. But almost every webfont proposal seems to be tied in 
some page/document format. The page metafor seems only needed to maintain 
'printability' of sorts, and as a somewhat stable basis to learn to think 
in a new techonolgy. Certain web developments are already moving away 
from the idea pages, like the (probably useful for somebody) window-panes 
in NetScape 2.x. How about toolpalets, dialogs, layered data, etc. These 
wont print easily, but will become necessary for building advanced 
interfaces and allow better graphic and application design.

>(does the I in this paragraph mean that only one of the people cited
>at the start agrees?)
Sorry, people listed at the top of the original message are just 
interested parties, not necessarily contributors. This post was/is by 
Erik van Blokland, and in parts of Just van Rossum. We both are 
typedesigners as well as [typo]graphic designers for print as well as 
electronic media. We have gained quite some experience in dealing with 
things that have to live in both worlds and many platforms, i.e. 
compromises.

>I agree that this would be a good feature.  It's a shame that Type 1 fonts
>generally have to be one-bit-deep.  I've used systems like NeWS that
>supported colour PostScript fonts.  But earlier you talked about not
>introducing complexities, or new features, or extra cost...
But would be an utterly cheap and already available feature. Any system 
that can show RGB images than suddenly can show colored type. It would be 
considerably more difficult to make this happen with outline fonts. .

>What happens if there aren't enough colours to display all the colours in
>a font?  How does the browser ensure that the page is still readable?
This problem already exists, and it is already being dealt with, though 
usually bluntly. How do CDrom authors figure out what system their CD is 
played on? By writing on the box you need some minimal hardware.  Note 
that there is a _huge_ difference in deciding on what the minimal 
configuration is, and going for the absolute maximum on the (not yet) 
available technology scale. Like certain websites that advertise the fact 
that one has to have a particular browser and a whole bunch of plugins in 
order to view the pages. This might not be the way to go if you want to 
reach many people.
Pinning down a minimal configuration is necessary for even the simplest 
websites, this is done by weighing the things one wants to provide, and 
the machines that your audience has. Perhaps there is something like a 
virtual screen, being an 8bit 640*480, and a virtual page something 
between an A4 and USLetter on a black and white laserprinter. Although 
this 'machine' will become more advanced as time passes, for all intents 
and purposes it can be considered constant.

>Again, I'll mention the TrueDoc system because it's the one I know
>most about....  the font arrives in an encrypted format.  The user can
>save it on the local hard disk -- big deal.  FontMonger won't open it,
>and neitehr will Suitcase on the Mac, nor anything else but a compatible
>Web browser.  
That is only a matter of time. Remember how long the tough encrypted 
PostScript type1 format remained a secret? 

>Adobe and Agfa and Bitstream would not be interested in this kind of
>technology if it were otherwise.  Their lawyers would be _very_ interested,
>of course.
Do you mean that by saying they are, it must mean that the technology is 
secure enough?

>Font embedding _will_ happen, with outline fonts.
Well, some fontembedding will happen.

>I think it's really good that typeface designers participate in this process.
You're welcome. ;-)

{{Ah! response!}}
{{It seems www-font@w3.org has a big mailinglist, but not much talk.}} 
{{Or perhaps there is something wrong with the remailer.}}

------------------------------------------------------------------
|--      |                       -|-             
|   /-| -|-   |/|/| /-| |/ /-|    |  | | |/| /-| 
|-    |  |    | | | | | |  | |    |  | | | | | | 
|   /-|  |    | | | | | |  |-/    |  | | | | |-/ 
|   | |  |    | | | | | |  |      |  |/| | | |   
|-- |/|  |/   | | | |-/ |  |-/    |    | |-/ |-/ 
                                     --/ |       
erik van blokland                                                         
        
www.letterror.com
------------------------------------------------------------------

Received on Thursday, 28 March 1996 16:10:42 UTC