There was a problem in extended some years ago when tcl/tk 8.5 broke a lot
of font stuff by trying to do too much automatically, which caused some
cross-platform trouble. I ended up having to make a wrapper for linux that
momentarily changed the screen DPI, since 8.5 would use that to size fonts,
and would get it wrong. I have no clue what happens now, but maybe this
will be helpful:

http://markmail.org/message/ssygglbvuz6mdkjz

On Sat, Oct 3, 2015 at 12:20 PM, Jonathan Wilkes via Pd-list <
pd-list@lists.iem.at> wrote:

> > 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.
>
> Actually, I'm not at all certain if its the Pd font metrics.  It may be
> that the font engine uses different
> inter-line spacing, or that tcl/tk reports the wrong metric, or something
> else.  The point is that if your
> message box is 400 pixels high and the text that fills it is only 380
> pixels high, Pd calculates cursor
> position based on the _box_ size.  As you add more lines to the box that
> discrepancy grows until
> it becomes nearly impossible to move the cursor or select text accurately.
>
> -Jonathan
>
>
>
> On Saturday, October 3, 2015 12:12 PM, Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at> wrote:
>
>
> 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 <reduz...@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
>
>
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to