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

-font-size 10 -font-face "Consolas"

Other fonts than those listed in the tcl will work, as long as they are fixed width (monospace). Google, and a trawl of your font library should find a good one.
Pd jumps to "8" as you say, if you try "9", but that might be a limitation of the actual font.

Otherwise, with later Ubuntu, people have had problems with the default graphics driver, but I think that just meant that outlines and cords were wrongly drawn....... but.......?
David.

That's one problem -- the other one is that as I said, 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.

But for the other problem...... if the -font-size flag works on none of the distributions then that must be surely be a problem with Pd, as it is Pd that is given the flag.
Unless the X-window system is overriding the Pd setting / not allowing changes / requires a font registration for each app?
David.

Did you read those two messages? I thought these passages spelled it out the issue rather succinctly:

When I switched fromUbuntu 14.04 to 16.04, boxes grew horizontally by one pixel per character for patches with fontsize=10.

When you switched to 16.04, you started using an updated font
engine to render the fonts. As far as I can tell there is no set of rules
or constraints on the font stack developers to keep font sizing algos
consistent across time. I do know that Windows, OSX, and the old
Gnu font stack sizing algo (i.e., 14.04) were within a pixel of each
other when measuring the width of a 31-characterfor string of
DejaVu Sans Mono at a particular pixel size. The newer Gnu font
stack rendered a string that was seven pixels wider at the same
pixel size.

and:

On further digging, I think the culprit is a slightly different tk scaling value:
Tk 8.4 -> scaling: 0.999016715831
Tk 8.6 -> scaling: 0.9990167158308751
Looks like a precision/rounding issue after all w/ 11 digits versus 17.

There's more later when they start talking about which app should be fixed Pd or tk, parameters to change before compiling to defeat the rounding, how to identify this specific error as opposed to all the other font problems etc. but no definitive solution yet.

It should be noted that this is a Vanilla-only issue. All the details on the other Pd distros relative to this problem can be found in that thread.

All that you say is true, but as Debian Sid is a currently "unstable release"... bleeding edge...not even released for testing except by developers (and stable Debian does not have this problem) https://wiki.debian.org/DontBreakDebian I think you are putting in a lot of work for no gain.

As the rendering is handed over to the OS, I still suspect the x-code or the graphics driver. A Ubuntu user found a solution to a very similar rendering problem by using his OS in a virtual machine.... https://forum.pdpatchrepo.info/topic/10884/pd-interface-rendering-bug-on-ubuntu-16-04

That you cannot set the -font-size flag on any Linux distro is an issue though, that maybe can be fixed easily if you report as a bug.
Yes, I still find extended more reliable and useful..... but a really massive effort was put in to make it so....
David.

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.

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.

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).

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.

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.

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)....