Re: [Gnome-print] PATCH: support freetype
- From: Akira TAGOH <tagoh redhat com>
- To: Lauris Kaplinski <lauris ximian com>
- Cc: gnome-print ximian com
- Subject: Re: [Gnome-print] PATCH: support freetype
- Date: Thu, 23 Aug 2001 00:03:58 +0900 (JST)
Hi,
>>>>> On 21 Aug 2001 18:46:06 +0200,
>>>>> "LK" == Lauris Kaplinski <lauris@ximian.com> wrote:
LK> Hello Akira!
LK> Sorry, I skipped gnome-print list for some days.
LK> Tell me, how confident you are by these patches?
LK> The problem is, that gnome-print has currently emerged into
LK> 3 (yes, three) versions:
LK> Current stable (0.29)
LK> Current HEAD (gnome 1.4 unstable)
LK> gnome-2.0 unstable version
LK> There is TrueType/FreeType support built in both HEAD and
LK> gnome-2 versions. I am stabilizing HEAD now, but may still
LK> take some time, as there are additional changes (config), and I
LK> want to change font installation system to make it comply with
LK> LSB.
LK> I'll merge your patches, and play with them. If that makes the
LK> life easier now, I am all for integrating these. My only concern is,
LK> that gnome-print 0.30, if it is still from stable branch, has
LK> to be rock-solid. So please add as much testing from your side
LK> as well.
Well, I have made these patches on gnome-1-4-branch and
tested it. Ok, I will apply to HEAD and test it.
LK> Also, I do not like the idea of specific init/finish for
LK> gnome-print at all. After all, we cannot guarantee finish to be
LK> called anyways, as programs may crash etc.
LK> So I suggest moving freetype_init to face class initialization,
LK> and either:
LK> a) dropping finish at all
LK> b) moving finish to face_destroy, so if all faces are destroyed,
LK> we clean up everything. Alternatively there can be some
LK> timeout, so it really behaves like cache.
I hope a suggestion of b. I just tested it and it's working
well. Thanks!
BTW these patches is NOT perfects for i18n. Right now
gnome-print has a default font which is
hardcoded(e.g. Helvetica) these patches is working well by
the applications which intentionally can specify the fonts
by users, but the applications which doesn't support it may
be not able to display multibyte strings correctly. so I
propose that the fontmap has a language specific default
font. we can solve it by using a every languages default
font which got from fontmap instead of a hardcode font.
for example:
<font format="truetype" name="Kochi Gothic" version="0.0"
familyname="Kochi Gothic" speciesname="Normal"
psname="Kochi-Gothic" weight="Regular" italicangle="0"
lang="ja">
Also, I'm not working about pdf. so the pdf writer may be
not able to use the fonts which can handle with freetype.
needs some works, but will be not difficult.
LK> But otherwise I am very glad :) Thank you very much for your work!
LK> Best wishes,
LK> lauris Kaplinski
cheers,
--
Akira TAGOH :: at@gclab.org
tagoh@gnome.gr.jp / Japan GNOME Users Group
tagoh@gnome-db.org / GNOME-DB Project
tagoh@redhat.com / Red Hat, Inc.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]