[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    CC: Re: "new" wp for linux
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2004-04-13 21:34:08
Message-ID: 407C5CD0.3000902 () acm ! org
[Download RAW message or body]


Rod Smith wrote:
> James Richard Tyrer wrote:
> 
> 
>>albright wrote:
>>
>>>James Richard Tyrer wrote:
> 
> 
> [re: printing problems]
> 
> 
>>>>This makes KWord useless as a professional word processor.
> 
> 
> Indeed; I filed a bug report about one of the worst problems. (See
> http://bugs.kde.org/show_bug.cgi?id=56249 if you care.) I had a long
> exchange with a developer who went down the wrong track on debugging, then
> stopped responding.
> 
KWord-1.3 is much better.  However the spacing is still not the same as
OpenOffice. :-(  I'm not sure which one is correct, but I suspect that it
is OpenOffice.
> 
>>>I agree on that, but openoffice gives fine printed output for me
>>
>>Yes.  I presume that it uses its own font rendering system -- like
>>WordPerfect does.
> 
> 
> Yes and no. OO.o uses a font rendering system that's built directly atop
> FreeType (http://freetype.sourceforge.net). FreeType is also the basis for
> Xft, which is the font rendering system used by most modern applications,
> including KDE and GNOME programs such as recent versions of KWord and
> AbiWord. (Incidentally, AbiWord's printed output is much better than that
> of KWord, in my experience. It's also the only program I know of that can
> generate PDFs from documents containing TrueType fonts such that the fonts
> render properly in the PDFs, not as ugly and unscaleable bitmaps.) WP8's
> font rendering system predates FreeType. I don't know if Corel (or the
> company that actually did most of the work; I don't recall their name
> offhand) used some commercial library for the job or if they came up with
> Type 1 code of their own.
> 
> I would hope that any future version of WP for Linux (not the upcoming
> re-release of WP8, obviously) would use Xft, or possibly FreeType directly.
> That would enable use of TrueType as well as Type 1 fonts, and if the
> program uses Xft, there'd be no need to install fonts in any unusual way.
> 
The problem isn't with using FreeType2, it is what you do with it.

This:

http://freetype.sourceforge.net/freetype2/docs/glyphs/index.html

explains where Qt went wrong when it comes to WYSIWYG fonts.

NOTE: I should make clear that this is a Qt bug, so we don't really know
how to fix it.

As you noticed, the line lengths (actually it is the glyph sizes) vary with
the screen resolution.  Lets call this Screen rendering.

With Windows software, the line lengths vary with the selected printer
resolution.  Lets call this Printer rendering.

And, I would also like to add a system where the line lengths don't change
at all when you change either one -- the glyph metrics are those stated in
the font file with NO hinting.  I am calling that PostScript rendering.

With Screen rendering, FreeType2 is used to render the glyphs for the
screen resolution and then the same line length is used for printing.  I'm
not clear on what system GhostScript uses to render the fonts but I presume
that it uses unhinted rendering which makes the glyphs smaller.

With Printer or PostScript rendering, the fonts displayed must be scaled
and translated (FreeType2 has a library call to do this) after they have
been rendered and before they are anti-aliased to match the font metrics
either for the printer resolution hinted glyph size or the font metrics in
the font file for unhinted rendering.

There is an additional issue with Printer rendering that KWord and/or Qt
must know the resolution of the printer.

My best guess is that KWord-1.3 is currently using Printer rendering so
there are still slight problems.  This is still wrong, but not as bad.
What is needed is for Qt to use a method that will match GhostScript.

That is, for KWord to work correctly, Qt needs to add what I have called
PostScript font rendering.  Since it already has Printer font rendering
that appears to work, it should be fairly simple to add this feature.  Then
a word processor based on Qt should have the choice of:

	Screen
	Printer <dpi>
	PostScript

for the font rendering, and it should then work perfectly.

--
JRT

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]