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 to
work.  There are two hardcoded collections of font metrics-- one in font_fixed_metrics in that
tcl file, and another in s_main.c called sys_fontlist.  It looks like the one in the tcl file is used as
a point of reference against which tcl/tk can measure the font on the user's system.  But then
when you sent those metrics off to Pd, it takes them and compares them _again_, this time
against the sys_fontlist min/max x/y values.  That seems unnecessarily complex and prone
to error.

And I use "hardcoded" loosely-- for all the "pixel exact" talk wrt Pd-extended, you would think
that the sys_fontlist in s_main.c would never change.  Those numbers determine the max size
of msg/obj boxes; if you increase the maximum height/width there, then someone's perfectly
arranged patch in 0.39 could have overlapping objects in 0.46.  But they've been changed
slightly 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 problem
is with multi-line message boxes.  Typically, you end up with a bunch of extra space at the bottom
of the box.  (And tcl/tk doesn't let you control the spaces between lines of text so there's no way
to 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 GUI
port.  One of the side effects is that the characters of the font itself are noticeably larger than
they are in Pd-Vanilla.  For example, [get] in my port will touch the top of the outlet with the bottom
of the "g" character.  I've found that making the xlets light gray is a decent compromise, and that
things 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@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list