xforms-development
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XForms] XForms and TrueType fonts


From: Jens Thoms Toerring
Subject: Re: [XForms] XForms and TrueType fonts
Date: Tue, 3 Jun 2014 20:59:10 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,

On Tue, Jun 03, 2014 at 06:40:31AM -0400, Rouben Rostamian wrote:
> just wanted to let you know that your Xft demo compiled
> cleanly on Xubuntu after installing libxft-dev and a few
> other packages.  The two strings look of the same size to me.
> The Xft fonts are rendered smoothly.  The X11 show just a
> slight amount of pixellation.

Rouben, thanks for the feedback! And, yes, the libxft-dev
package (and the packages that also get installed with them,
at least on apt-based systems, but hopefully also with RPM)
are needed since the header files for them must be present.
Sorry, I forgot to mention that since for some reason I al-
ready had them installed and thus didn't think about it.

Rob also replied and told me that on his machine the Xft
font is quite a bit larger than the X11 font (i.e., con-
trary to what happens on mine). This seems to fit what I
have observed several times in the past, i.e., that for
the same program, when run on different machines, the font
sizes can vary quite a bit relative to the object sizes.

Well, to start with the positive side: when using Xft (no
matter what type of font) the sizes should be exactly the
same everywhere (assuming that the system knows the exact
screen resolution). So, different font sizes on different
machines should become a thing of the past;-)

Of course, this comes with a prize: if you have optimized
your GUI for a certain font size on a certain system things
suddenly may start to look a lot less nice (as it already
might happen if you'd run the program on a sufficiently dif-
ferent system).

There are also other things to consider. Font sizes were always
given in points (1/72 of an inch). But most programs use object
and other sizes in pixel units. That was never a good idea to
start with, but since monitor resolutions didn't change often
in the past (a far as I remember. monitors always had either
75 dpi or, in the last 15 years, mostly around 100 dpi) this
wasn't that much of an issue.

I've worried about the new trend to higher and higher screen
resolutions in the last three years. On these "retina-display"
type devices, a program with object sizes given in pixels, ad-
justed for a 100 dpi screen, will be much to small to use.
Worse, the font sizes, as they're in points, will be much too
large for their objects. We'll have to find some kind of solu-
tion for "legacy" applications and switch to points for new
ones, or programs using XForms will become unusable on modern
equipment in the forseeable future:-(

So I fear that the effort to correct for less then perfect
looking layouts due to somewhat changing font sizes will be
only one step. I hope that it will be possible to find some
solution that allows a smooth transition for "legacy" appli-
cations that were written with pixels in mind. For those that
use the "official API" (and don't e.g., set object positions
and sizes directly by accessing the members of the FL_OBJECT
structure) there might be a way, for others I'm sceptical.

And a third point is UTF-8 support. Those of you working with
programs in English only that isn't something too interesting.
Those that wrote programs using West-European languages could
more or less trust on a font with Latin-1 to be used, so most
things also more or less worked. But with the transition to
TrueType fonts that may change: most are for UTF-8, and the
"Latin-1 will work" assumption may break down (unless default
fonts are selected that use this encoding). If you have taken
a look at the test program you may have noticed the use of
XftTextExtents8(), XftDrawString8() etc. These obviousky are
for "a byte equals a character" programs. But there are also
functions for 16-bit and 32-bit character encodings, as are
for UTF-8 and UTF-16. In the long run, it very likely will make
sense to switch to e.g. UTF-8 for everything. This will require
quite a bit of work since the assumption that a character is a
byte is deeply ingrained everywhere you look in the code.

I'm unsure at the moment if a reasonable gradual, i.e. step-wise
transition is possible or if all this only makes sense when done
at once. And then there's also the question of time - at the
moment I'm not employed, so I've got some spare time, but my
funds are starting to dry up, so I'll have to look for work in
the near future (anyone knows about some nice job, maybe con-
tracting?;-) and then probably will have not too much time
to spend on XForms. And everything of the above together is
rather likely to be something that could require a number of
months of work.
                          Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]