Thanks. I haven't run any tests with custom DPI settings for the gui port.
But I'd be willingto bet all that works just fine since people can view
websites on Iphones.
-Jonathan
On Saturday, October 3, 2015 12:43 PM, Matt Barber <brbrof...@gmail.com>
wrote:
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 differentinter-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 cursorposition based on the _box_ size. As you add more
lines to the box that discrepancy grows untilit 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 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 <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
