<div dir="ltr"><div dir="ltr"><div>Hi Jonathan,</div><div><br></div><div>A very informative post. Indeed the font system should be taken care of otherwise a Linux update from troglodytes might just break everything...</div><div><br></div><div>Then a quick test on non-Western font support: <a href="https://imgur.com/a/rWJCApt">https://imgur.com/a/rWJCApt</a></div><div><br></div><div>When editing either an object or a message, the border correctly wraps up the text, as the border is either an outline or an <svg> with view box, both adapting to the width of the <p>. Unfortunately when the editing is done the box shrinks, computing the total width as if a Chinese character has the same width of a single DejaVu character in English, which is much narrower. If I'm not mistaken, this computation happens in the C code (void text_drawborder(...) in g_text.c), which is really bad news because we don't want to let the pd core differentiate whether a character is Latin or Chinese or Thai, etc. Perhaps we need to move that to GUI and send a message back to core so the core knows where the boxes are, but that requires a big overhaul.</div><div><br></div><div>That's just what I discover from looking at the code; again, for now I have no idea how to actually do that. If you need any testing from someone who is familiar with non-Western language I would definitely be glad to help. Maybe in the future I can also contribute the the revamp but for now I need to get the K12 proposal done first.<br></div><div><br></div><div>Best</div><div>Shaoqian<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 6, 2019 at 6:35 AM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi list,<br>
<br>
I'd like to draw up a plan for setting an arbitrary font at startup<br>
for Purr Data while some semblance of consistency and sanity across<br>
platforms. This is mostly for myself atm unless someone wants to go<br>
ahead and implement it. Alternatively, if someone wants to make some<br>
screenshot examples for the written explanations I'm giving that would<br>
certainly be helpful.<br>
<br>
The reason consistency is important is that a Pd user on OSX has<br>
absolutely no idea how fonts measure on Windows or Linux. And there's no<br>
cross-platform spec (nor even a single platform spec AFAICT) that would<br>
require a font at a given pixel size to actually conform to that pixel size.<br>
<br>
That's a problem because Pd users build patches using absolute positioning.<br>
Suppose a Windows user puts one message box [hello( at (0,0) and another<br>
message box [world( at (0, 40). Then they visually confirm that the result does<br>
not cause overlapping boxes and they ship their patch.<br>
<br>
Now suppose a user on Ubuntu opens that same patch. Perhaps this<br>
version of Ubuntu renders the font used for the text "hello" and "world"<br>
slightly wider, so that for example the word "hello" takes up 2 more pixels<br>
than it did when rendered in Windows.<br>
<br>
It's possible to code up a clever algorithm that checks the font width at<br>
startup and adapts the box size to accommodate the wider rendered text<br>
on Ubuntu. In fact that appears to be what Pd-extended attempted to<br>
do in tcl/tk at some point.<br>
<br>
But notice that this behavior actually *breaks* the "hello world" patch<br>
above. While the message box border would be correctly adjusted around the<br>
word "hello", that message box would now overlap with the message box<br>
containing "world." That's not what the Windows user wanted-- after all,<br>
they visually inspected the patch to avoid any overlaps. But overlaps are<br>
what the Ubuntu user sees with such a system.<br>
<br>
Now, you might decide to be even *more* clever and code up an algorithm<br>
that scales the origin of object/msg boxes based on the difference between<br>
the width of the rendered font and the ideal font width. But of course you'd<br>
hit nasty problems there with widgets like iemguis and ds scalars which<br>
can use arbitrary shapes and paths. Plus even if you took the time and<br>
complexity to scale those, people can embed images in their patches<br>
which cannot easily be scaled without affecting the quality.<br>
<br>
On the other hand, you might decide to be drastically *less* clever and<br>
make a rule that all boxes positioned in a row must leave at least some<br>
amount of empty space in between them to accommodate the possibility<br>
for font discrepancies. However, the same problem applies to<br>
font height and inter-line spacing as applies to font-width. So<br>
multi-line comments can "accordion out" and overlap on the Ubuntu<br>
user's machine<br>
while they look just fine for the Windows user. It's simply too much of a<br>
burden to expect users to keep these subtleties in mind when writing<br>
patches.<br>
<br>
The only sensible solution I see is to position and size boxes *exactly*<br>
the same on all platforms and then adjust font sizes so that they fit the<br>
default metrics given for each of the available Pd font sizes. This means that<br>
in some cases the boxes aren't tightly fitting around the text (e.g., on<br>
some Ubuntu versions where the fonts are rendered significantly wider than<br>
OSX and Windows). But it also means that a user can write a patch and<br>
be guaranteed that the boxes won't overlap on any of the other platforms.<br>
<br>
So here's a rought spec to do that:<br>
<br>
1. GUI must hard-code the default font metrics used in Pd Vanilla and send them<br>
off to Pd at startup as part of the "init" method. This will ensure backward<br>
compatibility with box sizing of previous versions of Purr Data and previous<br>
versions of Pd Vanilla. (Unfortunately Pd-extended changed those defaults<br>
for some of the font sizes, but I *think* size 12 is the same so at least that<br>
would be consistent.) This will also ensure forward compatibility with<br>
Purr Data. I hope Pd Vanilla hasn't changed those hard-coded metrics--<br>
if they haven't then we'll get forward compatibility with Pd Vanilla, too.<br>
<br>
2. We use an algorithm at startup to pick GUI font sizes that most closely<br>
to the hard-coded Pd default metrics without exceed the default<br>
height/width metrics. This means that a user who chooses Pd font size<br>
"12" isn't<br>
guaranteed to get a pixel-size 12 font. But that was never a guarantee in<br>
the first place, and Deja Vu Sans Mono seems to look quite crisp and readable<br>
even though we're using non-integer GUI font sizes on most platforms.<br>
<br>
3. Box borders are *always* drawn based on default Pd font sizing metrics.<br>
This guarantees all boxes in patches will be pixel exact.<br>
<br>
4. Comment boxes must show a border in editmode to communicate to the<br>
user the maximum size of the box. This way users can use that border to<br>
avoid overlaps on all platforms.<br>
<br>
5. Iemgui fonts-- ugh, I have no idea. Let's just say "you're on your own" and<br>
try to get the *single* sys_fontsize working correctly for arbitrary fonts.<br>
<br>
Currently, there's no algorithm to do the size picking at startup.<br>
Instead we're<br>
just checking for that weird Ubuntu wide-font case and scaling things down<br>
so that they fit into the boxes.<br>
<br>
So I guess the first thing to do is to implement an algorithm that selects the<br>
GUI font sizes that are hard-coded in font_map and suboptimal_font_map at<br>
startup. If we can generate the values for font_map on the fly then we'll have<br>
a good starting point.<br>
<br>
Next thing would be to figure out some sensible interface to replace<br>
gobj_font_y_kludge. Those values were just from testing on each platform,<br>
and luckily the Ubuntu edge-case didn't affect font heights at all. That may<br>
be trickier to get right.<br>
<br>
Finally, we need some way to get data about non-Western languages and<br>
how they fit into this. Technically we could get rid of sending font metrics<br>
with the "init" message, but perhaps non-Western characters require a<br>
different set of default metrics for Pd patches to be usable/readable in those<br>
languages. If anyone has some links related to that it would be helpful.<br>
<br>
Best,<br>
Jonathan<br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div>