nanogui: Thread: Re: Logical font support

: The announced patch to make use of the logical font system is now
: finaly nearing completion.  There are a couple of things involved
: and some changes to the logfont structure.

I have added your complete patch to the master tree.
However, there are quite a few issues that may
need to be resolved.  In addition, the Microwindows
branch didn't compile after your patch, and a number
of things needed to be changed.  I'll try to summarize the 
issues below.


: This is what the patch contains:
: 
:  1) A new option, -c <filename> which reads the file and parses
:     it for configuration information.  Currently, it is only
:     used for defining fonts, but can be used for a lot of things
:     if the simple parsing that it does is sufficient.

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.

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.  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?
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...

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 specification would be the same as
the fonts.dir method, which would allow Linux/X fonts to be used
easily.

"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.

In addition, after your patch, the existing t1demo and ftdemo nano-X
demos stopped working.  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.  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.


:  6) A modified MWLOGFONT structure, that now looks like:
: 
: typedef struct {
:   long    lfHeight;               /* desired height in pixels*/
:   long    lfWidth;                /* desired width in pixels or 0*/
:   long    lfEscapement;           /* rotation in tenths of degree*/
:   long    lfOrientation;          /* not used*/
:   long    lfWeight;               /* font weight*/
:   MWUCHAR lfPitch;                /* font pitch (width) */
:   MWUCHAR lfItalic;               /* =1 for italic */
:   MWUCHAR lfOblique;              /* =1 for Oblique (kind of Italic) */
:   MWUCHAR lfRoman;                /* =1 for Roman letters (upright) */
:   MWUCHAR lfSerif;                /* =1 for Serifed font */
:   MWUCHAR lfSansSerif;            /* =1 for Sans-serif font */
:   MWUCHAR lfModern;               /* =1 for Modern font */
:   MWUCHAR lfMonospace;            /* =1 for Monospaced font */
:   MWUCHAR lfProportional;         /* =1 for Proportional font */
:   MWUCHAR lfSmallCaps;            /* =1 for small caps */
:   MWUCHAR lfUnderline;            /* =1 for underline */
:   MWUCHAR lfStrikeOut;            /* not used*/
:   MWUCHAR lfCharSet;              /* font character set*/
:   MWUCHAR lfOutPrecision;         /* font type selection*/
:   MWUCHAR lfClipPrecision;        /* not used*/
:   MWUCHAR lfQuality;              /* not used*/
:   char    lfFaceName[MWLF_FACESIZE];      /* font name, may be aliased*/
: } MWLOGFONT, *PMWLOGFONT;
: 
: It contains a lot of strange stuff.   For instance, there are three
: true/false variables for Roman/Italic/Oblique.  This probably seems
: unneccesay complicated, and I'm not sure if I like the idea 100%, but
: it has the benefit of making it possible to classify a font fairly
: detailed (e.g. the distinction can be made between oblique and italics).

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.

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.


: This system is not complete yet, but I'd like to hear your comments
: on the code and any suggestions that you may have.  Also, I have not
: tested this code against the FreeType library, but I would expect it
: to work, as there is basically no difference except for how the
: physical font is named in the config file (FT,<fontname> instead of
: T1,<fontname>).

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...

I will produce a 0.88pre8 shortly, with the patch included.

Regards,

Greg

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