Hello,

Could anybody help me with the following font problems please...

DPI Differences
===============
As far as I know this is the following default DPI settings on various platforms.

- 75 dpi for Mac OS
- 96 dpi for MS Windows
- auto detect or 110 dpi for X11, though I have seem many applications an distros force a 96 dpi setting like Windows.

Now as far as I know this makes fonts look difference in size for the same font height. Is this only true when the font size is defined as pixel heigh, or does it also apply when font sizes are defined in points height as well?

Some Examples
=============
From my own experience, this is what I have found. Under Windows, the default system font size is 8 points (not 100% sure if this is points or pixels, but I believe it's points?). To get the same look (font height) under Linux, I need to set my X11 applications to use 10 points size fonts. Strangely enough, that is also the case even if I force my X11 to use 96 dpi like Windows. Why is that?

Now under Mac OS X (I just read this in the Mac HIG document), the standard (normal size) font is Lucida Grande Normal and is set to 13 points. Judging by 1:1 ratio screenshots, those fonts appear the same size as my X11 applications (under Linux) set to 11 points font size.

Questions
=========

- So why is there a difference in size between all the platforms?

- I first thought it was dpi related, but setting Linux to run at 96 dpi and Windows to 96 dpi there is still a size difference. Windows 8 point = Linux 10 point. Why?

- If I create a cross-platform application that uses a non-default font (not like what Lazarus LCL does by default), how am I supposed to set the font size, so the UI text looks consistent in size no matter the platform?

Regards,
- Graeme -

Since the printer output of Linux is often in Postscript format, and postscript uses 72 dpi, 72 dpi would also be nice to have !

Best regards,

Geoff

Geoff Bagley wrote

Since the printer output of Linux is often in Postscript format, and postscript uses 72 dpi, 72 dpi would also be nice to have !

Well under Linux with X11 you can force whatever dpi you wish. Here is an example where I force 100 dpi for X11.

$ startx -- -dpi 100

Regards,
- Graeme -

Graeme Geldenhuys wrote

- I first thought it was dpi related, but setting Linux to run at 96 dpi and Windows to 96 dpi there is still a size difference. Windows 8 point = Linux 10 point. Why?

And here is the exact same issue shown using a web page with CSS.

http://jongrieve.net/faq/dcss/

So the issue is wide spread, but still I don't know why. Also does that mean I need to apply the same font size hack as the guy in the CSS article.

eg:
ifdef MacOS
NormalFontSize = 13
elseif Windows
NormalFontSize = 8
elseif Linux
NormalFontSize = 10
else
NormalFontSize = 8 // ??? What would be correct as a default?

   Label.Font.Size = NormalFontSize;

Yuck!!!! Imagine that all over your code? Is the ifdef part could be done in some Constants.pas unit and used globally in your application, but still it feels like a hack. Not to mention it makes GUI design a lot more difficult if the same form is edited on various platforms.

Regards,
- Graeme -

Even single platform it is a mess if you work e.g. in team. My windows DPI is different from the one from my collega, and when I open his files or vice versa, the .dfm files of delphi are all messed up. What will happen at the client, is even more of a mystery... This has been plagueing us since day 1.

Michael.

I can't remember if it was Lazarus, Delphi or Kylix (CLX) that added the dpi value inside the Form File, but from what I remember in Kylix & Delphi (CLX apps), we experienced that mess as well - design time and runtime.

What will happen at the client, is even more of a mystery...

I'll rather not mention that to my boss. :-)

This has been plagueing us since day 1.

Crap, so I gather Lazarus LCL doesn't have an answer either. :-( Thanks anyway...

Regards,
- Graeme -

If we use Point or pt in CSS it must be same in all OS or systems 8pt it is the size in the screen or printer page it is like to say 1 Inch we must not care about the DPI.

Point is 1/72 of Inch.

The same headache also between "Internet Explorer" and Firefox for who developing Web/CSS.

Hello Lazarus,

Tuesday, July 7, 2009, 2:33:07 PM, you wrote:

GG> DPI Differences
GG> ===============
GG> As far as I know this is the following default DPI settings on various GG> platforms.

GG> - 75 dpi for Mac OS
GG> - 96 dpi for MS Windows
GG> - auto detect or 110 dpi for X11, though I have seem many GG> applications an distros force a 96 dpi setting like Windows.

GG> Now as far as I know this makes fonts look difference in size for the GG> same font height. Is this only true when the font size is defined as GG> pixel heigh, or does it also apply when font sizes are defined in points GG> height as well?

And also default font could be very different across platforms and even in the same platform. To "solve" both problems in my cross platform applications (Linux and Windows) I'm using a self designed ScaleBy function which in the design platform takes some parameters, like a test string width, and scales all visual elements in the form to preserve look. Of course it will change the width and height of the scaled forms. The main problem is that some visual objects must not be scaled for any reason, and there is no way to prevent it, anyway they are not common.

Maybe something like this functions can be added to the LCL to get compatibility with "ScaleBy"'s Delphi.

Attached is the current code, it has not been finished and only checked in in some quite simple forms.

I'm usually developing in Windows environment with 96 dpi and a font "normal" for Windows XP. In the formCreate event I'm writting:

const LAZYFOXSTRING=76;
procedure TfrmMain.FormCreate(Sender: TObject);
begin
  //Scale for Pixels per inch, designed is shown in the form properties (96).
  ScaleByRecursive(Self,Self.PixelsPerInch,Screen.PixelsPerInch);
  //Now scale for a font proportion
  ScaleByRecursive(Self,LAZYFOXSTRING,Self.Canvas.TextWidth('Lazy Fox Jumps'));
.....
end;

Where the "LAZYFOXSTRING" is the "Lazy Fox Jumps" width in my development environment.

A solution similar to this is what I have adopted for cross-platform font size compatibility.

However to avoid polluting the code too much I make almost universal use of the ParentFont property (ie, assigned True) and assign the font at the root of the visual hierarchy (usually the form) at runtime based on the platform DPI. It works well when all your widgets use the same font.

On a related note, I asked this questions a while back but got no replies. Anyone?

Cheers, Bruce.

The dpi and default font size should be considered together, because they make standard text appear to the user in *his* preferred size. While every platform has a different opinion about *how* the user should specify his preferences, the resulting default font size in pixels should be understood as a *user* specific constant.

Unfortunately multiple monitors can have different resolutions, so that they may have different dpi values. But IMO this should not require to scale forms differently for every monitor, because the desktop management of every platform most probably will use common parameters for the entire desktop.

This is why Microsoft in Visual Studio uses Twips (1/20 pt) instead of pixels, for all component positions and extents. In Delphi such scaling is implemented by the Scaled and PixelsPerInch form properties.

Of course it will change the width and height of the scaled forms. The main problem is that some visual objects must not be scaled for any reason, and there is no way to prevent it, anyway they are not common.

Delphi controls have a ScalingFlags property, indicating which properties already have been scaled. A second property of that type could indicate *which* of these properties should [not] be scaled at all, so that scaling could be turned off for graphical controls which contain neither text nor scale nicely (bitmaps...). Or a single boolean value [Scaled?] could specify whether the control has to be resized at all, while its position always should scale together with all other controls.

Nice concept :-)

DoDi

JoshyFun wrote

And also default font could be very different across platforms and even in the same platform. To "solve" both problems in my cross

So basically this is a total mess for Lazarus, Kylix and Delphi. :-( How does other cross-platform toolkits handle this? For example Qt or wxWidgets? Or maybe more interestingly, Java?

Maybe something like this functions can be added to the LCL to get compatibility with "ScaleBy"'s Delphi.

We used to use that in Delphi and Kylix CLX applications. It was a mess as well!

I'm usually developing in Windows environment with 96 dpi and a font "normal" for Windows XP. In the formCreate event I'm writting:

So if you change your monitor to say a Widescreen LCD or downgrade your Windows XP to Vista, then you might have to search and replace the value of LAZYFOXSTRING for all the applications you every developed and still maintain? :-(

Regards,
- Graeme -

Bruce Tulloch wrote

However to avoid polluting the code too much I make almost universal use of the ParentFont property (ie, assigned True) and assign the font at the root of the visual hierarchy (usually the form) at runtime based on the platform DPI.

But currently my Windows and Linux use the same 96 dpi setting, yet the 8 pt font under Windows is the same size as a 10 pt font under Linux. So the dpi value doesn't seem to be the only culprit. I'm using Arial on both platforms as my default font in my applications.

Also, I follow a mixed bag of UI Guidelines - font sizes similar to Mac OS X. I use different size fonts in one form.

For example (under Linux):
- Normal Font is 10pt and used in Labels, Button Captions etc..
- Small Font is 8pt and used for extra descriptions below components or for tick captions in a Slider component etc.. The content of Grids also use Small Font.

Regards,
- Graeme -

I don't think they guarantee that the application looks 100% the same on all platforms.

Michael.

Graeme Geldenhuys wrote

But currently my Windows and Linux use the same 96 dpi setting, yet the 8 pt font under Windows is the same size as a 10 pt font under Linux. So the dpi value doesn't seem to be the only culprit. I'm using Arial on both platforms as my default font in my applications.

Indeed DPI does not seem to be the only "difference". I've simply specified the point size in an #IFDEF clause at application instantiation time based on the detected O/S and platform that I have found "just works" but it may in fact not work for everyone :-(

Also, I follow a mixed bag of UI Guidelines - font sizes similar to Mac OS X. I use different size fonts in one form.

Unfortunately that probably means you're stuck with a need for more font fixup coding. I guess in that case I'd recommend abstracting the font specs required into globally accessible TFont instances created at application start and set up based on O/S and platform and then use these to establish the fonts for all your widgets that require them. At least that way the #IFDEF'd O/S and platform detection part is in one isolated place in the application.

-b

I've the opposite experience with apps in general if I compare fonts between windows and linux. On my linux, using the same dpi, the same fonts look bigger and fatter than on my windows.
Event when I run a xserver on windows, with a smaller DPI than my windows, the fonts are bigger.

Anyway, back to lazarus, fonts defined in points should look to have the same size on different dpi.
Years ago I wrote that I woulf have a look to get it right for Lazarus, but that time didn't come :(

Marc

Marc Weustink wrote

Anyway, back to lazarus, fonts defined in points should look to have the same size on different dpi. Years ago I wrote that I woulf have a look to get it right for Lazarus, but that time didn't come :(

So basically some form of a layout manager or alignment MUST be used to at least keep things in relative proportions. All components must be auto sized to keeps things from working and looking correctly.

No wonder so little Windows applications are ported to Mac or Linux. The developers know the potential issues and simply choose to not go there. ;-)

Regards,
- Graeme -

I was thinking more about a solution to this problem.

What if we move away from the point sizes and rather give it a name like: ExtraLarge, Large, Normal, Small, Tiny etc... Then each platform implements the size name to what they consider the valid point size (taking into account dpi settings).

eg: Based on a 96dpi on Linux and Windows and 75 dpi on Mac

Font Size Linux Windows Mac
=================================================
Large 12pt 10pt 15pt
Normal 10pt 8pt 13pt
Small 8pt 7pt 11pt
...

So when you specify Font-Size = Normal, it looks the same sime (or very close) to what you intended, no matter the platform.

fpGUI Toolkit already uses what is called a Font Alias (or Font Description) when specifying fonts in components. Obviously the developer could specify fonts in the normal fashion as well (real font name, size, attribute).

Examples of Font Aliases as used in fpGUI Toolkit: (font aliases are denoted by a # prefix)

'#label1' = Arial-10:antialias=true
'#label2' = Arial-10:antialias=true:bold
'#edit1' = Arial-10:antialias=true
'#edit2' = Courier New-10:antialias=true
'#grid' = Arial-9
...

So I could probably define new font alias called #Large, #Normal, #Small, or modify the existing aliases. Then under each platform (platform specify backend units) specify the preferred point size for each of those. That way my applications can still continue using the Font Alias as normal when specifying a font. Ummm... that could work.

Here is an example of setting a font for a component using Font Aliases
- as used in fpGUI Toolkit:

   Label1 := TfpgLabel.Create(self);
   with Label1 do
   begin
     Name := 'Label1';
     SetPosition(8, 16, 104, 30);
     FontDesc := '#Label2';          // font defined here
     Hint := '';
     Text := 'Some Caption';
   end;
   Edit1 := TfpgEdit.Create(self);
   with Edit1 do
   begin
     Name := 'Edit1';
     SetPosition(116, 16, 160, 34);
     TabOrder := 1;
     FontDesc := '#Edit1';          // font defined here
     Text := '';
   end;

Regards,
- Graeme -

Graeme Geldenhuys wrote

What if we move away from the point sizes and rather give it a name like: ExtraLarge, Large, Normal, Small, Tiny etc... Then each platform implements the size name to what they consider the valid point size (taking into account dpi settings).

I forgot to mention, would something like this be viable to Lazarus LCL? Introducing a FontDesc property?

Regards,
- Graeme -

Hello Lazarus,

Wednesday, July 8, 2009, 8:24:17 AM, you wrote:

HPD> The dpi and default font size should be considered together, because HPD> they make standard text appear to the user in *his* preferred size. HPD> While every platform has a different opinion about *how* the user should HPD> specify his preferences, the resulting default font size in pixels HPD> should be understood as a *user* specific constant.

That's the reason I wrote ScaleBy to not force the user to use "my" font choose and always try to use his/her settings.

HPD> This is why Microsoft in Visual Studio uses Twips (1/20 pt) instead of HPD> pixels, for all component positions and extents. In Delphi such scaling HPD> is implemented by the Scaled and PixelsPerInch form properties.

Twips... they drives me crazy in my VB years :)

HPD> Delphi controls have a ScalingFlags property, indicating which HPD> properties already have been scaled. A second property of that type HPD> could indicate *which* of these properties should [not] be scaled at HPD> all, so that scaling could be turned off for graphical controls which HPD> contain neither text nor scale nicely (bitmaps...). Or a single boolean HPD> value [Scaled?] could specify whether the control has to be resized at HPD> all, while its position always should scale together with all other HPD> controls.

I found no way in LCL, I'm not running Delphi since a lot of time. Any scale concept should be IMHO or very simple 1,2 more properties or quite complex covering almost all combinations. Trying to do almost every possibility with only a few properties is usually a big problem.

HPD> Nice concept :-)

Thank you. The main advantage is that you can register a specific ScaleBy procedure for special controls or derived ones. The rest of the code is quite simple.

I wonder that, it is happened when the system convert Points to Pixels when create the font.
for example
8pt in 96dpi
8*96/72=10.6666 pixels
in Windows it convert to 11 pixel, i do not about Linux but if it trunk the integer and get only 10, the font appear smaller.

Try to change the font Height property that given in pixels to be" -10" instead of "-11" and see the differences.

Zaher Dirkey wrote

8pt in 96dpi 8*96/72=10.6666 pixels in Windows it convert to 11 pixel, i do not about Linux but if it trunk the integer and get only 10, the font appear smaller.

Using Bitstream Versa Sans Mono font and setting it to 8pt I typed the following text: lygA?

Using Gimp I took a screenshot and measure the top of '?' to the bottom of 'g' and it was 12 pixels high. The letter 'B' is 8 pixels high. I'm running my X11 and a forced 96 dpi. Using Ubuntu 8.04.2 with Gnome desktop.

So again, using your formula, I have no clue why fonts vary in size depending on different platforms yet using the same dpi setting. It seems everybody has there own formula for converting points to pixels.

Regards,
- Graeme -