W3C home > Mailing lists > Public > www-font@w3.org > January to March 1996

Re: WebFonts

From: Andrew Pennock <andypen@microsoft.com>
Date: Thu Mar 28 12:22:11 1996
To: www-font-request@w3.org
Cc: "hannes@dataweb.nl"@microsoft.com, "hoefler@aol.com"@microsoft.com, "www-font@w3.org"@microsoft.com, evb@knoware.nl, gregh@microsoft.com, Wenzel@dataweb.nl
Message-Id: red-58-msg960328172103MTP[01.52.00]000000bf-10403
Hello All

I agree with a lot of the arguments Lee puts forward for an outline 
format rather than bitmaps. The variety of screen resolutions and 
operating systems combined with the diversity of human preferences 
makes a scaleable outline an obvious choice.

Although people like the idea of reading on screen, there has to be a 
significant improvement if people are to read more than a few 
paragraphs on screen before they print it out. As the quality of the 
whole web medium improves, hopefully people will read more on the 
screen but they will also print more out, so it is always better to 
have the best of both worlds.

Font embedding will address a lot of concerns in that it allows web 
authors to safely use any fonts they want and shrink them to a small 
percentage of their original size.

1) The subsetted font that the embedding generates will be in a format 
that is useless until it is reconstituted by the browser and not much 
use to the end user (other than for viewing the web page) because of 
the small character set and short duration of its visit.

2) Existing and agreed levels of embeddability are set by the font 
makers themselves, so when a print & preview font is sent down with a 
document, it is installed on the users machine and deleted afterwards.

3) Font embedding will take whatever fonts you use at the authoring 
end, subset them down to only the characters needed to build that page. 
Combine this with lossless compression and you get a very small file 
size with no loss of fidelity.

It is also true that most people who buy fonts for commercial & design 
reasons purchase Type 1 fonts because they are most familiar with them. 
It is probably also true that the majority of web pages are rendered 
and read using TrueType system fonts because they are most legible on 
the screen.

I may be slightly biased towards TrueType, but it has some distinct 
advantages that should be seriously considered.

Thanks for your time.

Regards
Andrew Pennock -- Microsoft Typography






----------
| From: www-font-request@w3.org
| To:  <"Wenzel@dataweb.nl">;  <Wenzel@dataweb.nl>;  <"evb@knoware.nl">;
| <evb@knoware.nl>;  <"hannes@dataweb.nl">;  <hannes@dataweb.nl>
| ;  <"hoefler@aol.com">;  <hoefler@aol.com>;
| <"www-font@w3.org">;  <www-font@w3.org>
| Subject: Re:  WebFonts
| Date: Wednesday, March 27, 1996 8:50PM
|
| > From: Erik van Blokland <evb@knoware.nl>
| > To: "Hannes Famira" <hannes@dataweb.nl>, "Martin Wenzel"
| <Wenzel@dataweb.nl>,
| >         "Jonathan Hoefler" <hoefler@aol.com>, "Www" <www-font@w3.org>
|
| > Scalability
| > Having outlines available at the client makes it possible to scale the
| > text and print a page.
|
| 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.
|
| > Some sort of anti-aliased bitmap font will do just fine.
| We have users with black-and-white (not greyscale!) terminals.
| They can use an outline font.  They can't easily use a greyscale bitmap.
|
| > Printing
| > Other argument: printing a webpage. First, are there figures available on
| > the amount of webpages that actually get printed?
|
| Not that I've seen.  I can tell you that we had very high demand to add
| printing to HoTMetaL and HoTMetaL PRO, the SoftQuad HTML editors.
| We also had strong demand to add printing support to the free version of
| SoftQuad Panorama, the SGML browser.
|
| > 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.
|
| Nothing is more complicated or expensive than it need be.
|
| Your argument would also apply in this scenario, I think:
|     Most computer-printed documents were generated with Microsoft Word.
|     Microsoft Word does not use ligatures.
|     Fonts would be simpler, smaller and cheaper without ligatures.
|     Therefore, fonts should not contain ligatures.
|
| 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.
|
|
| > Secondly, typography for the screen is different from typography for the
| > printed page. Unless screen and pages actually become the same physical
| > object, a design for one medium will always look bad on the other. Not
| > just because of the fonts, the typography for each medium requires
| > different solutions: the way the text is read differs.
|
| I think this is a good argument for separate style sheets for printing --
| as supported by SoftQuad Panorama PRO, and by the current HTML stylesheet
| proposals.
|
| [...]
|
| > Economy
| > Outline font are more economic (smaller) compared to a bag of bitmaps
| > that contains all sizes one could make with the outline font. That makes
| > it a good solution for desktop publishing where you don't know what the
| > next job will bring. But a web page contains a limited number of
| > characters in a limited number of sizes. Up to a fairly large bodyheight
| > a pre-rendered bitmap font is smaller than an outline font describing the
| > same thing.
|
| 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.
|
| However, for reasons outlined above, anything using a bitmapped font is
| doomed to failure, even if the format you use is the Microsoft Windows
| ".fon" format or the Adobe/X11 .bdf format, both of which are already
| widely implemented.
|
| > The letters can be even be colored with many colors in one letter and
| > modified using normal image processing software. This is, I think, a must
| > for popular acceptance of a type on screen system, just look at what
| > people are doing with text in images on the web right now.
|
| (does the I in this paragraph mean that only one of the people cited
| at the start agrees?)
|
| 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...
| 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?
|
| > Copyright & piracy issues
| > As a typedesigner I've seen and experienced how people deal with fonts
| > and ownership, and it sucks. If a system came to be where
| > character-outlines are broadcast to every single browser in the world I
| > would stop making type, or at least, stop using anything nice and new
| > because it would become instant public domain.
|
| If this were true, I would strongly oppose outline fonts on the web.
| So would many other people on this mailing list (and elsewhere!).
|
| One reason why it hasn't already happened is the effort involved in
| making sure that the fonts can't easily be re-used.  It has to be at
| least as hard as getting a font out of a PDF file, say.
|
| 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.  Some proposals allow the same screen font to be used in
| multiple documents (but you won't generally have all the characters you
| need!).  Personally I favour being able to use a font fot all the web
| pages at your site.  But none of the proposals I've seen let you receive
| a font associated with a web page's style sheet and use it yourself.
| The font is never installed on the system.
|
| 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.
|
| Font embedding _will_ happen, with outline fonts.
|
| A better question, it seems to me, is
| ``how do we work together to make sure the result is as good as possible?''
|
| By `good', I mean (most important first, roughly)
| . Sufficiently secure
| . Supports those people who need (or whish to use) Accessibility options,
|   such as audio screen readers, braille conversion, `large print' editions,
|   and other requirements.
| . Wide range of commercial high-quality `font software' (typefaces)
|   readily available
| . Supported in commercial Web authoring tools and browsers, such as
|   HoTMetaL, SiteMill, InternetAssistant, and NCSA Mosaic, Netscape,
|   Internet Explorer, etc...
| . Highest feasible rendered quality
| . Fast as possible
| . Internationalised -- e.g. not restricted to a `Latin 1' character set,
|   but can use Unicode in conjunction with script/language tagging as per
|   the HTML Internationalisation Internet Draft to access a full range of
|   Hangul, Kanji, Roman, Hebrew..... glyphs
| . Platform independent, so that Mac users can join in too
|   (at least one proposal I have seen excludes the minority of WWW users
|   who are on the Macintosh, for example... oops) (please don't ask which)
| . Device independent, so that what you see on your screen is as close as
|   possible to what I see on mine
| . Supports printing adequately.
| . Possible to use existing investment of Type 1 fonts.  (The ability
|   to use TrueType fonts might also be important, but I claim that most
|   people who pay for commercial professional-quality typefaces today
|   buy Type 1 fonts.  One day, QuickDraw GX will be ported, and GX fonts
|   will also be possible on non-Mac computers, but not yet)
|
|
| I think it's really good that typeface designers participate in this
| process.
|
| Lee
|
| Liam Quin, SoftQuad Inc +1 416 239 4801 lee@sq.com
| HexSweeper NeWS game;OPEN LOOK+XView+mf-fonts FAQs;lq-text unix text
| retrieval
| <URL:http://www.sq.com/> SoftQuad Panorama, HoTMetaL, Services, SGML tools
| `The future holds promise for those who have faith in it' [Inglis billboard]
|
|
|
| 
Received on Thursday, 28 March 1996 12:22:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:37 UTC