Just so people know why dia handles fonts as it does, I will go over some
of the basics. First of all, we want dia to display fonts the same on
screen and exported to any other format.
Unlike web pages where everything will still work if a user only has
Helvetica on their system and the web page wants Verdana, dia needs to be
a bit more precise. Consider some shape that contains a box with some
text inside it. If an alternative font that is a bit wider is chosen, the
text may overlap the box in the exported file (we already see this problem
with the exported CGM files with some viewers).
When dia was started, the primary output formats were on screen with X,
and postscript. The easy way of handling this was to limit the usable
fonts to the standard postscript ones, and using the matching X fonts.
If you wish to use more fonts in PS output, it would be necessary to
inline the type1 files in the document (since not all
printers/interpreters will have access to the font). For this to work, we
need access to the type1 fonts. Now even though most X servers can handle
type1 fonts, an application has no way to request the location of the
type1 file corresponding to an X font, so this information would need to
be found some other way (the X server will only return bitmap
representations of fonts).
Two ways to find the type1 fonts are to scan the system (what gnome-print
does), or install new fonts with the program (what abiword does).
If you have access to the outlines for the font, it would also be possible
to convert the font glyphs to curves and render the text manually when
exporting, as suggested. This has the downside that the text is no longer
recognisable as text, which may be a problem if we are exporting the file
so it can be editted by a different program.
Now if we add i18n and different to the mix, this is even more difficult
to do correctly. If we were going to change the print/font system of dia
radically, I would probably lean toward using one of the libraries that
already exist (such as gnome-print). Yes this means another library, but
it means less system configuration required than if dia had its own
handling.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
On Tue, 25 Jan 2000, Ronald L. Chichester wrote:
> "Cyrille Chepelov (home)" wrote:
> >
> > On Tue, 25 Jan 2000, Dave Airlie wrote:
> >
> > > so my main use for CGM would be editable-imports into MS-Word (no choice
> > > here), so I am wondering how much trouble it would be to use truetype
> > > fonts with dia and the CGM exporter.... I have ttf in my X system all
> > > ready ...and would this solve the problem with the fonts in MS Word at
> > > least?
> >
> > James: what about doing something in the CGM output like the file
> > "t1-to-svg.c" in Gill does ? This could be user-configurable, some might
> > even find that useful. Or maybe that would just bloat the output.
>
> The problem with fonts is difficult. It is not so much that you have
> the fonts loaded on your system (although that helps). The bigger
> problem comes when you load that file on another system that does not
> have those fonts. Then something (software) or someone (wetware) has to
> decide what alternative font gets used and how to use it. All too often
> the results are not pretty. Worse, there is also the display issue (X)
> versus the printing issue (Ghostscript). Both have to be solved to make
> a workable solution.
>
> Because Linux does not have an easy method for handling fonts, it is a
> safe bet that most people to whom you send a dia file will not have
> non-standard *ix fonts. Thus display and printing of the sent file is
> problematic.
>
> This is a problem that is not specific to Dia. I'm a beta tester for
> Corel's WordPerfect 2000. Moreover, I've had this same problem with the
> Gimp. Both of those programs have to contend with the font issue in a
> critical fashion. I hate to say it, but fonts are one place where the
> Windows world is way ahead of the *ix world. (But then again, those
> guys in Redmond always liked form over substance.)
>
> I have some rather bitter experience with fonts on my network (I'm an
> intellectual property attorney that doubles as a sysadmin for the firm's
> Linux network). The lack of font support is one of the biggest factors
> against converting from M$ to Linux.
>
> To solve this problem, it would be helpful to devote some effort into
> making the installation of fonts as easy as possible. Creating a font
> installer for Gnome would be a great start. Collecting freeware fonts
> into a central repository (e.g. http://fonts.gnome.org/) would be
> another suggestion.
>
>
> Ron
> ./.
>
