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

Can anyone else confirm that -font-size does nothing? Doesn't work on any linux I've tried, haven't had a chance to check the Mac version. Windows... nah I don't do that...(but It would be informative to people who do...)

@NoDSP It all works fine on Windows. OSX I have not heard of problems since Pd addressed them in 2011. Ubuntu, some problems after 16.04 (and sometimes before... but X-window). Generally a lot of Linux font problems on Google.
Sorry I am not helping with your particular problem.
You could try a.... sudo apt-get install --reinstall x-ttcidfont-conf ttf-dejavu....... if not done so already.
I am having trouble understanding why it should be a tcl issue when it works fine on other Linux distros.
Tk 8.4 was a problem..... but it's very old now......
But Pd will need a re-write (again) just for newer Linux. I don't know what other problems that will throw up for system compatibility. There was a long debate about it last time.
David.

@whale-av Yes as I mentioned I tried all those ancient tricks on puredata.info and no dice. Some of those apt-get package suggestions have been replaced in Sid so there's some ambiguity there but there's reason to doubt that's the issue because it's not just one distro or desktop environment (and yes, I even messed with all the desktop font configs I could find).

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.

@NoDSP Yes, I tried to read very carefully all of the research that you have done (and more).

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.

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