[Top][All Lists]

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

Re: [XForms] XForms and TrueType fonts

From: hohe72
Subject: Re: [XForms] XForms and TrueType fonts
Date: Tue, 3 Jun 2014 23:27:18 +0200

_Debian 3.2.57-3+deb7u1 i686_

Changing resolution via: xrandr --output LVDS1 --dpi 120
influences the Xft-text size, but not the X11 one. 

XftFontOpenXlfd() or XftFontOpen() makes no difference.

The anti aliased text widens the box due to half tone pixels.

Great work,

Jens Thoms Toerring <address@hidden> wrote (Tue, 3 Jun 2014 20:59:10
> 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

reply via email to

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