Re: A DVI viewer with freetype2

[Cesar Crusius]

* Werner Lemberg (address@hidden) [000405 00:23]:

> Doing this will make people in CJK countries not very happy since
> you remove CJK support...

I don't get it. It would remove CJK support only until someone writes
a CJK module for freetype2.
 
> VFlib is a marvellous piece of software (with some rough edges,
> though), and I would prefer if people really use it in the Western
> world -- have you ever looked into VFlib's companion package,
> TeX-Guy?  For example, it comes with a X DVI previewer which has
> been written with 400 lines only!

In my opinion, a font library should be one consistent piece of
software. VFlib is a good solution while we don't have that, but VFlib
is a conglomerate of a bunch of font libraries. Although the external
API is consistent, the internals have to be bloated in order to cope
with all differences between the parts. Also, it encourages divided
effort for the same task - after all, there are multiple rendering
engines (freetype1, t1lib, ...), so that if t1lib comes up with a
better renderer, freetype1 doesn't make use of that, and as a result
different fonts are rendered with different quality. 

Now that freetype2 will accept any font format I see no reason for
VFlib anymore. The amount of work put into VFlib is huge, and I admire
who did it being a programmer myself.  But I guess work will be more
fruitful if it is redirected to new modules for freetype2.

I too had a library project (OffiX) that was going quite well (hi
Stefan!). But I bumped into a better thing and realised that going on
with my OffiX was wasted time in a sense. I switched to this better
thing, and now what was good in OffiX has been incorporated in Berlin
(which btw uses ggi and freetype), so there is no reason for OffiX
anymore. VFlib is good, but the freetype2 concept is better.

-- 
Cesar Augusto Rorato Crusius      o__     o__     o__     o__     o__
Stanford University               ,>/'_   ,>/'_   ,>/'_   ,>/'_   ,>/'_
e-mail:address@hidden        (_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_)
www.stanford.edu/~crusius

HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE
LOSES BOTH AND DESERVES NEITHER