Been testing some Debian Sid based distros w/Pd and ran into a font problem I can't seem to fix.

When I load patches created with only the default avalable fonts on a string of previous Debian-based systems (the last being Ubuntu 14.xx) with no issues, the object font is too large or wide and throws off the alignment of the patch. Not sure if it's the wrong size, a fixed-width variant or the wrong font but it's definitely wrong. All of the GUI programmed fonts are fine.

I've found that the -font-size startup flag will do nothing on any system I've tried it on so either my syntax is wrong (tried quotes, no quotes, etc) or that flag doesn't work. I can use -font-face to change the font to a smaller one, but Pd still calculates the width of the box by the "wrong" font (only the box height changes). The only setting that comes close to a "quick fix" for this is the Edit menu font option, I've always left this set to 10. If I drop it to 8 it will change both the width and size but now it's just a bit too small.

Now if I could set it to 9 I just might get away with it but there is no nine. I don't know if I could send a nine manually over some control channel but -- I really shouldn't have to mess with any of those settings, should I?

Any Ideas what's really going on? The old suggestions at purdata.info don't seem to help. All my systems are running the same compiled source on the same hardware.. Tried the last 2 or 3 versions of Pd Vanilla with the same result.

Edit: It does seem the 2 sid distros I've tried lack the oldest of the multiple versions of tcl/tk that the previous installs have.

Edit#2: Uh oh this may be part of the problem:

https://lists.puredata.info/pipermail/pd-list/2017-02/117898.html

https://lists.puredata.info/pipermail/pd-list/2017-02/117886.html

@whale-av In that first passage I quoted, the Pd list member is saying he's getting the exact same problem in Ubuntu 16.04 LTS -- not sid, not a test or development release.

As far as that other 16.04 graphical rendering problem you linked to -- no, that problem is not "very similar". There's no problem with graphical renderings -- this is only related to the display of the default object box font.

If you really think pursuing this is "a lot of work for no gain" you might want to tell the list developers that -- in that thread they seem to have determined it's a real issue worthy of their attention.

@NoDSP Sorry sorry sorry..... only trying to help.
Text is a graphical rendering too, only very much more complicated, with anti-aliasing etc.
I meant it's work for you for no gain....... the great programmers on the list are indeed doing a lot of work and will hopefully solve these problems that have cropped up again like a bad penny.....
David.

Not sure if it's related but we ran into some font engine problems in Purr Data last year that showed up in ubuntu 16.04.

Apparently somebody somewhere in the Gnu font stack "fixed" font-rendering such that a monospaced font like DejaVu Mono got rendered with a measurable difference in width compared to OSX, Windows, and every earlier Gnu font stack I could check.

Here's my comment about it in the Purr Data workaround:

+var font_engine_sanity;
+
+// Here we use an HTML5 canvas hack to measure the width of
+// the text to check for a font rendering anomaly. Here's why:
+//
+// It was reported that Ubuntu 16.04, Arch-- and probably most other Gnu/Linux
+// distros going forward-- all end up with text extending past the box border.
+// The test_text below is the string used in the bug report.
+// OSX, Windows, and older Gnu/Linux stacks (like Ubuntu 14.04) all render
+// this text with a width that is within half a pixel of each other (+- 217).
+//
+// Newer versions of Ubuntu and Arch measured nearly 7 pixels wider.
+//
+// I don't know what the new Gnu/Linux stack is up to (and I don't have the
+// time to spelunk) but it's out of whack with the rest of the desktop
+// rendering engines. Worse, there's some kind of quantization going on that
+// keeps the new Gnu/Linux stack from hitting anything close to the font
+// metrics of Pd Vanilla.
+//
+// Anyhow, we check for the discrepancy and try our best not to make newer
+// versions of Gnu/Linux distros look too shitty...

In Purr Data, systems using this new font stack will notice a small amount of extra padding at the right of the box. This is because as I mentioned the font engine quantizes the pixel font size such that fitting it to the box makes it slightly smaller than what would be ideal. Rather than making the box smaller, I purposefully keep the box size consistent across all platforms so that users on Ubuntu 16.04 and greater don't end up putting boxes so close to each other that they end up overlapping when viewed on Windows/OSX.

Hope that helps.

@jancsika Thanks for the explanation Johnathan. I was losing sleep trying to understand how it could be caused by anything other than changes in the Linux font rendering engine.......
David.

For what it's worth, I was able to more or less "fix" the sizing/spacing problems with my patch by following the instructions at the top of this page:

https://github.com/pure-data/pure-data/wiki/Crossplatform-font-metrics-%26-comparisons

Not an ideal solution, wish I knew what the heck those upstream guys are thinking (or not thinking).

I linked to this related thread from here:

https://forum.pdpatchrepo.info/topic/11063/pd-0-48-font-size-issue

with some additional notes on the font startup flags from the Pd list.

I can confirm now that this is definitely a linux version specific issue. I just checked three releases of UbuntuStudio -- 14.04, 16.04, and the new 17.10 (forgot to grab 15.10). Out of those three only 16.04 has this issue. The Sid install which I "fixed" with the above linked workaround is now aligned with Debian 9.

Hope we can write this one off as a passing upstream fumble. Would be nice to know of a specific component in 16.04 that could be replaced.

I'm aware this is an old thread, also for Linux, but just wanted to remark on this:

the -font-size command line startup flag does absolutely nothing on any system I've tried it on. Doesn't matter what size I set it to high or low it still loads the same default size.

I kind of noticed something similar, Purr Data 2.15.2 on Windows 10. I tried calling it with

pd.exe -font-face 50 -font-face "Consolas"

... and indeed, whatever old patch I opened, still had the old font size .... However, if I did Ctrl-N for a new patch, then Ctrl-1 to place an object, then start typing - then that font is indeed large ... So, it is possible that font size gets saved with the object in a .pd file.

However, my problem now is, that the -font-face never gets honored (font face remains the same, no matter what I use for -font-face)....

@sdaau_ml Font size just sets the font size for new patches, if you want to change the font size of an old patch just open it in a text editor and the first line will be something like #N canvas 584 41 781 712 10;, last digit is the font size, change as needed. PureData does this because it does not reorganize the patch after a font switch, open a patch in a text editor and triple the font size, open it up and PD and see what happens, everything will be an illegible mess because the objects all retain their old positions.