- From: Erik van Blokland <evb@knoware.nl>
- Date: Thu, 28 Mar 96 22:10:19 +0100
- To: <lee@sq.com>, "w3 webfonts" <www-font@w3.org>
>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