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

List:       koffice-devel
Subject:    Fwd: Re: [Issue N21701]  Kword & fonts
From:       Vadim Plessky <vplessky () faringosept ! ru>
Date:       2003-05-17 7:48:42
[Download RAW message or body]


Some comments from TrollTech regarding issues raised.

----------  Forwarded Message  ----------

Subject: Re: [Issue N21701]  Kword & fonts
Date: Wednesday 14 May 2003 13:17
From: qt-bugs@trolltech.com
To: Vadim Plessky <vplessky@faringosept.ru>
Cc: qt-bugs@trolltech.com

On Saturday, 03. May 2003 19:42 Vadim Plessky wrote:
> On Friday 02 May 2003 14:15, David Faure wrote:
> |  On Friday 02 May 2003 11:54, Chris Osicki wrote:
> |  > It is hard however to say for sure if what I see on the screen is
> |  > really Helvetica.
> |
> |  I think it is, but if you zoom to 400%, I guess the characters
>> won't zoom
> | - which is a bit of a problem ;)
> |  (At least without Xft. With Xft I haven't retested this recently).
>
> Most Linux distributions substitute URW Sans L  for Helvetica.
> Current distributions focused on GNOME (read: RedHat/Rawhide) put
> Bitsream
> Vera Sans as a substitution.
> I guess you get one of those.
>
> |  > When printed it _is_ Helvetica but, character spacing is smaller
> |  > than the one of the printer's "native" font. I compared printouts
> |  > from Kword and this piece of PS:
> |  >
> |  > 100 200 moveto
> |  > /Helvetica findfont 20 scalefont setfont
> |  > (kjsaldjfslakfjaslkfjaslfs) show
> |  > showpage
>
> Most likely, Helvetica would be substituted with URW Nimbus Sans L at
> *GhostScript level*.
> Check settings for your GhostScript interpreter, I think there is a
> substitution table like this.
> If you want *real Helvetica* - you need PostScript printer with
> *original
> Adobe PostScript* (like Xerox Docuprint N series)
>
> |  > The same text printed from Kword is about 10 mm shorter.
> |  > I wold expect it not to change any font's characteristics when
>
> not
>
> |  > asked to.
> |
> |  The eternal WYSIWYG problem. We first decide where characters will
>
> go,
>
> |  based on the font metrics we get from the fonts at a given size
>
> (100%
>
> | zoom), and then we use those positions at any zoom level, and when
> | printing. So if the font isn't truly proportional, i.e. it would
>
> need its
>
> | characters to be more spaced, or less spaced, than the metrics it
>
> gave at
>
> | 100% zoom, then there is trouble ahead. Before the WYSIWYG
>
> implementation
>
> | (i.e. in KWord-1.1) the text would be relayouted with the new font
>
> metrics,
>
> | and the whole layout of the document would change (and people
>
> rightfully
>
> | complained about that). Now with the WYSIWYG implementation, the
>
> layout is
>
> | guaranteed to stay the same, but the characters don't always look ok
>
> ...
>
> | especially with bitmap fonts, which are usually not proportional at
>
> all.

There is nothing that can be really done with bitmapped fonts. This is
the main reason Windows removed most of them and doesn't really offer
them for word processing.

The thing that should be done for scalable fonts is to use design
metrics for layouting (ie. the metrics you would get at an infinite
resolution). Qt currently doesn't support using design metrics, but
this can be approximated by scaling the metrics of the font at a rather
large pixelsize (eg. 64 or 128 pixel).

> Let's hope we have correct layout at least for Scalable fonts (PS,
> TTF)
>
> | Worse, it seems GS gets different font metrics? I'm not sure what to
>
> do
>
> | about that....
>
> GS gets metrics from AFM file (which complement PS Type 1/ Type3 .PFB
> / .PFA files). AFAIK, Qt (and therefor - KDE) ignores AFM files, while
> FreeType offers support for AFM metrics (and therefor - not only for
> character width but kerning as well) I beleive this is a Qt bug
> (_missing feature_) and should be fixed at Qt level.

No, I'm pretty sure freetype doesn't use AFM files. It doesn't need to
as it can open the font directly and read out the design metrics. AFM
is only ment to be a help for applications that can't interpret the
postscript fonts themselves.

The main problem here is that Qt doesn't offer some way of getting and
using design metrics for some font. It's a thing on my list, but for Qt
3.2 I considered support for indic languages more important. We will
get back to this and try to iffer support for WYSIWYG and design
metrics in Qt itself at some point.

> |  David, who hates fonts now, and who welcomes any help on this
>
> problem.

Lars, who also hates fonts... ;-)

--
Lars Knoll, Senior Software Engineer
Trolltech AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway

-------------------------------------------------------

-- 

Best Regards,

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net

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