Subject:
Re: Logical font support
From:
Morten Rolland ####@####.####
Date:
10 May 2000 19:19:52 -0000
Message-Id: <3919C456.A677DC49@screenmedia.no>
Greg Haerr wrote:
> After looking at your nano-X.cfg file, my feeling is that
> it's quite a bit too complicated. Also, all initialization from
> a config file needs to be done at the engine level, otherwise
> it won't apply to the Microwindows API. Currently
> this is performed in nanox/srvmain.c.
I'm not very familiar with Microwindows, as you have painfully
noticed, so I did put the configuration functions itself into the
engine, and the file parsing in Nano-X. The parsing can equally
well be done by the engine, but I was unsure of the best way
WRT microwindows initialization. The code should be easy to move.
> The .cfg file has tons of info in it, all in a new format, and
> will be confusing for anyone trying to add fonts to the
> Microwindows system.
Hmm, if you have to modify a font file yourself, I would claim
that the X11 format is the worst of the two. It is also less
flexible, except for (at least) one thing: Font size. The
current logical font system is unsuited to handle bitmapped
fonts, as you can't map based on sizes - should be fixed.
The reason why it has "tons" of info is that I wanted it to be
descriptive of the font, rather than categorize it. Some info
may not be used, yet, and some info like the oblique info is
almost identical to itlaic, and redundantly encoded, but it
holds some more possibilities than a single enum, which I think
is important as the current logical font API depends on a binary
structure that can't be easily improved after rollout (binary
compatibility for the API will become more important as time
passes).
Actually, I would like the system to be able to handle the
differences between "designer" parameters and "apparent"
parameters, too. Example: The current 'weight' can IMHO have
two meanings; how black or thin the font is on a linear scale,
and on the other hand if the designer meant the font to be bold
or not. These are not the same thing, as some designs have
normal and bold, others have normal and demibold etc.
It should be possible to ask for "50% weight" and get something
that is aprox. as black as some other font at 50% weight, while
two fonts specified as "Bold" could have different weights (and
differ visually, weightwise). I don't know type design or
typesetting, so please comment on this. It would make things
more complicated, for sure. But the descriptive info should be
present if it exists and is well defined IMHO. Making use of
it can be up to the application, or a future font selection
scheme.
These are all ideas, more pressing needs limits the time for
experimenting with such issues.
> Most of the parameters are
> reworks of a fonts.dir file, except that all the names and
> ordering is changed. I'm thinking two things: first, rather
> than spending hours creating/updating a .cfg file every time
> you want to add a font, why not just have Microwindows
> understand the X fonts.dir format, with very small changes?
This could be done - but would it be as flexible? It did take
quite some time to go through the 35 PostScript lookalike fonts,
I admit, but I think the work that went into it improved the
value of the resulting font descriptions. I may be wrong.
> For instance, with the URW fonts that you recommend
> using, why not just use the already contributed and working
> fonts.dir file with the addition of aliasing? The .cfg file
> could then look like this:
>
> alias "Times Roman" -urw-Helvetica-*-*-*-*-*-*-*-*-*-*
> xfont a0100113l.pfb -urw-Avantgard-book-r-normal--0-0-0-0-p-0-iso8859-1
> xfont a0100115l.pfb -urw-Avantgard-demibold-r-normal--0-0-0-0-p-0-iso8859-1
> ttfont arial.ttf
> fontpath /usr/local/lib/mwfonts
> etc...
You may be right, but when you later need more information it would
have to get added on, and a not so nice and orthogonal system might
result?
> In this way, the alias feature would allow a facename string to
> specify a foundry, facename, and other attributes before looking
> at the plogfont struct.
The foundry could be added for the alias, I realise this can be
a problem in some situations.
> "xfont" specifies that the font will be specified in X fonts.dir format.
> "ttfont" specifies that the font is TrueType and it's attributes will be
> read from the font itself. The renderer can be determined from
> the font extension.
This is OK with me. The various configuration methods can be a compile
time option to save space, even.
> In addition, after your patch, the existing t1demo and ftdemo nano-X
> demos stopped working.
This is extremely embarrasing - sorry about this!
> This is because the semantics of GrCreateFont
> changed. I have fixed it with the following: If plogfont is specified
> in the GrCreateFont call, then it works according to your patch. That is,
> Microwindows gets the fontface and height from the plogfont struct. If,
> however, plogfont is NULL, then the fontname and height are taken
> from the first two parameters, and used as physical name, rather than
> a logical name.
Gee - this is what I thought I designed my patch to do, and it did, at
times at least... I'm Sorry that my QA slipped big time here.
> This allows programs to specify the font file directly
> if desired, skipping the logical font process completely. This would
> also allow the select_font routine to be omitted for size, which
> would be nice on smaller systems. Ideally (not yet), the passed
> physical name in this case would also go through the aliasing mechanism,
> if enabled.
I think these are very good ideas - putting all the font stuff into the
same file is probably not a good idea. We can even have one file
for each of the font rendering methods.
> I think that Italic and Oblique is too complicated. Also, having
> separate Serif and SansSerif is complicated. An enum instead
> of a boolean would be better, with a don't care, serif, sans-serif,
> and modern.
This is because of my desire to describe a font rather than
categorize it. What I really wanted to do was describe a font in
an internal format, and have a more "user friendly" API that is
extensible. I don't think the current MWLOGFONT structure is
as flexible as it can be (a "binary" struct carved in stone; we
are struggeling with something similar in the nwidget set right now,
and it can be very annoying). I have been toying with the idea of
setting attributes by calling a function that takes a font handle,
a function (an integer), and the value. This is much like the
'ioctl' API in the linux kernel.
The good thing about the "ioctl" method would be that new parameters
or attributes or modes can be set by introducing a couple of new
#define and not changing any user-space aware MWLOGFINT structure.
I guess what I propose is put the MWLOGFONT struct inside the
font-handle in the Nano-X server, and make a function to assign
values/activate attributes in the font handle.
These are things I probably can't afford to look too much into right
now, as we are nearing an (internal) release/milestone date, and
we will have to concentrate on bug fixes and our own code.
> There still isn't any place to specify a foundry, without resorting
> to an alias in the .cfg file. I had foundries specified with integers,
> but that's removed now, and replaced with pitch, with a different
> meaning.
I didn't like the integer solution, because it is very static. The
retionale behind not being able to alias a foundry was: If the
application demands adobe fonts, that should be acknowledged. If no
adobe fonts are available, try a font with same font name.
I see that this causes problems if you have, say, two competing
Times fonts, none of them adobe, and an application wants 'adobe'
fonts and you want all requests for adobe fonts to map to a particular
substitute font family.
This should not be to hard to fix.
> My comments are just as the result of trying to get the patch
> working. (I'm using freetype, not t1lib, and the thought of converting
> all the URW fonts to .cfg format from the fonts.dir file was
> way too daunting....) Perhaps a best answer would be to allow
> differing font select algorithms, by moving select_font out of
> engine/devfont.c. With the name/height semantics changed back
> to allow filenames, this may allow everyone to be happy...
Thanks for looking into this - I didn't want to cause any trouble,
but things are flying by at a rapid pace here now..
> I will produce a 0.88pre8 shortly, with the patch included.
Thanks a lot! I will submit another patch soon, with the code
needed for implementation of an on-screen keyboard and pointer
device through an external application (as I wrote in an
earlier letter). This should be a nano-X patch only - I hope..
I would be immensely greatfull if you would consider this for
inclusion as well, as it is the last missing piece of an API
framework that can sustain our needs as far as I can tell,
except from speed optimizations and some improvements that needs
more investigation. QA testing (memory leaks, crashes etc.) will
be investigated, and results/patches published.
Thanks a lot,
Best regards
Morten Rolland, Screen Media
