[PD] Font size on Windows and Linux

[Jonathan Wilkes]

What font are you using?

I have to admit that after looking at Pd's font system, I have no idea how it's supposed towork.  There are two hardcoded collections of font metrics-- one in font_fixed_metrics in thattcl file, and another in s_main.c called sys_fontlist.  It looks like the one in the tcl file is used asa point of reference against which tcl/tk can measure the font on the user's system.  But thenwhen you sent those metrics off to Pd, it takes them and compares them _again_, this timeagainst the sys_fontlist min/max x/y values.  That seems unnecessarily complex and proneto error.

And I use "hardcoded" loosely-- for all the "pixel exact" talk wrt Pd-extended, you would thinkthat the sys_fontlist in s_main.c would never change.  Those numbers determine the max sizeof msg/obj boxes; if you increase the maximum height/width there, then someone's perfectlyarranged patch in 0.39 could have overlapping objects in 0.46.  But they've been changedslightly over the years, so I don't think I'm the only one who doesn't understand the system.

Additionally, Pd-extended standardized the default font on each platform to be DejaVu Sans Mono.I could be wrong, but I think Miller uses a different font.  The main place this becomes a problemis with multi-line message boxes.  Typically, you end up with a bunch of extra space at the bottomof the box.  (And tcl/tk doesn't let you control the spaces between lines of text so there's no wayto fix it.)  This becomes more than an aesthetic problem-- for example, if you try to move the cursor,Pd moves it based on Miller's font metrics, not the users.  This means that for large message boxes,when a Pd-extended user tries to select a line of text it will select the text a line or two above that.
At the moment, I've got DejaVu Sans Mono perfectly size to fit Miller's sys_fontlist in the GUIport.  One of the side effects is that the characters of the font itself are noticeably larger thanthey are in Pd-Vanilla.  For example, [get] in my port will touch the top of the outlet with the bottomof the "g" character.  I've found that making the xlets light gray is a decent compromise, and thatthings are generally more readable.  (I'm also not using bold typeface.)
I was also going to try Droid Sans Mono Dotted because I read that it covers CJK characters.But in my tests it looks like DejaVu does as well, so I haven't done that.

-Jonathan
   

  On Saturday, October 3, 2015 2:24 AM, Roman Haefeli <reduzent at gmail.com> wrote:
   

 Only after having access to more Windows virtual machines, I realize
this is an issue only on _one_ Windows machine (unfortunately, the one I
did the most of the testing with). 

Sorry for the noise (that caused no reaction anyway).

Roman

On Don, 2015-09-10 at 14:43 +0200, Roman Haefeli wrote:
> Hi all
> 
> It's old news, but deken makes Pd-vanilla _the_ target platform and I do
> care about portability:
> 
>  Font sizes in canvasses are different between Linux and Windows.
> 
> Some patches created on Linux break on Windows because symbol boxes are
> overlapping the GOP area and are not visible anymore. 
> 
> From the list of available sizes in the 'Edit'->'Font' menu, only a few
> sizes are actually affected. The sizes 8, 10 and 12 are one pixel per
> character wider on Windows than on Linux. The sizes 16, 24 and 36 are
> OK.
> 
> Now the question is what is the correct way to fix that, I mean on what
> platform should it be changed? I'd say it should be changed on Windows,
> because I can't imagine that shrinking boxes would break any patches,
> while widening boxes might do. 
> 
> Pd-extended already dealt with the issue and apparently found a fix.
> What would speak against incorporating that fix into Pd?
> 
> Roman
>  

_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151003/857bc2ad/attachment.html>