Re: Text label mis-sizing / clipping

[Alexander Malmberg]

Adrian Robert wrote:
> 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?

Nope. It also wouldn't help. The hard-coded coordinates are measured in 
points, too.

> > 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.)

Well, that's not _my_ recommendation, but if there's space and there's 
no visual impact, there's no reason not to. :)

> 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.

You mean that the interfaces would have to be redone? In practice, you 
have to do that anyway, so I don't think that's a significant problem.

> Also, while Gorm could perhaps be modified to
> enforce the needed generous sizing automatically,

2. is easily done in Gorm by using Vera Sans as the system font when 
designing.

> 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.

I'm not sure what you mean here. R is auto-sizing, and if you use code, 
you can either use auto-sizing or do what'd you do for Gorm (ie. design 
using Vera Sans; you don't have to use when the design is done).

> 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.

I don't think that would be acceptable.

> 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.
[snip]

There are no pixel sizes involved anywhere, but you could compare the 
width (in points) of some suitable string. However, I don't think this 
scheme would be worth the trouble. I consider auto-sizing to be the 
solution, and, failing that, making things big enough for Vera Sans 
makes them big enough for most other fonts.

(Note that you could achieve something similar manually by just setting 
the NSFontSize default.)

- Alexander Malmberg