Re: [XForms] XForms and TrueType fonts

[hohe72]

_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,
Holger



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