Re: Text label mis-sizing / clipping

[Adrian Robert]

> Although applications can specify the font and font size, standard 
> fonts may resolve to different actual fonts on different systems, so 
> "System Font 12pt" might be rendered as "Helvetica 12pt" on some 
> systems and as "Vera Sans 12pt" on other systems, and these have very 
> different metrics.

Thank you for this clarifying information.  It sounds like the problem 
is font requests are communicated from app to system in terms of 
point-size instead of some pixel-based metric.  Assumedly pixel-based 
communication could not be implemented without changing the app-visible 
API, correct?


> Anyway, although neat flamewars are possible based on this, I'll just 
> state my recommendations:
>
> 1. Create auto-sizing interfaces.
> 2. Design for Vera Sans (since Vera Sans is large enough that most 
> other fonts, and at least all standard choices for system font, will 
> fit).
(Also, 3. just leave, say, 20% extra space for labels in UI no matter 
what.)

I don't want to ignite any flames, but I wonder if there is an 
alternative. ;-)  While (1) is ideal in theory, in practice we have a 
framework (appkit/gui) and interface design tool (IB/Gorm) that have 
long made fixed layout their bread and butter.  Even if we make a 
conscious decision to use more autolayout, and manage to convert our 
existing apps, problems will still come up with porting.  (2) would 
also have this problem.  Also, while Gorm could perhaps be modified to 
enforce the needed generous sizing automatically, it would be difficult 
for Renaissance and from-scratch developers to work this way if they 
didn't want to use Vera Sans in the final product.

We could try going the OS X route, where you basically cannot set 
system fonts, and provide a fixed set of default fonts packaged with 
gnustep-back for each back end.  This limits user choice.

But what about this possibility instead: is there some point within the 
text rendering pipeline for gnustep that a metric measurement could be 
made, and if a mismatch exists between pixel-based size of the 
designed-with font and the size of the runtime candidate with same 
point size, the runtime one be substituted with a sufficiently smaller 
point-size version?  This would be done once per font request, based on 
a fixed, representative string.  It wouldn't be perfect, but would 
probably avoid clipping most of the time while still leaving a 
consistent-looking interface.

I realize that there are a host of issues here:

- this could lead to unexpected results in the printing pipeline if 
different print fonts are available than screen fonts

- some mechanism is needed to store what is essentially design-time 
information (NOT compile time!) information in an app 
(Info-gnustep.plist, maybe?)

- can/should such font substitution just be done for certain types of 
widgets -- i.e., labels and dropdowns, but not, say, TextViews ?

- layout problems could occur when porting an app from gnustep to OS X

- APIs that query for font point size could be affected

All of this might be a hassle to deal with, but if it could be done 
once and done right, the user experience would definitely benefit.