<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Maybe we should design a Pd gridfont (see <a href="http://cogsci.indiana.edu/gridfonts.html">http://cogsci.indiana.edu/gridfonts.html</a> ). Every letter is just line segments connecting dots on the same standard grid, so you wouldn't need to worry about metric translation at all -- just specify the dimensions of the grid in pixels. Of course then Pd would have to include an engine to draw them... Anyway I'm partial to "hunt four."</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 9, 2015 at 7:42 PM, katja <span dir="ltr"><<a href="mailto:katjavetter@gmail.com" target="_blank">katjavetter@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Oct 9, 2015 at 4:42 PM, Jonathan Wilkes <<a href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>> wrote:<br>
> The patch developer can't get reproducible appearance<br>
> with iemguis across platforms:<br>
> * the patch developer is almost never able to know what<br>
> fonts are available on the other platforms<br>
> * the patch developer can't know the actual metrics of<br>
> the font on those platforms<br>
> * there's nothing in the iemgui properties that tells the user<br>
> the first font in the list is supposed to be guaranteed to exist<br>
> on all platforms (and is supposed to be DejaVu Sans Mono), and that the<br>
> other two may vary<br>
<br>
</span>True, there can't be a guarantee, patches have to be tested on all<br>
platforms but with Pd-extended I was able to get almost uniform<br>
appearance across platforms.<br>
<span class=""><br>
><br>
> Where do you get your information for how a pixel-size font<br>
> is defined? I've never seen anything written or tested that<br>
> to conclude that if I pick "10px" as my font size the font<br>
> engine _must_ render the font exactly 10 pixels from<br>
> ascender to descender.<br>
<br>
</span>Some bits:<br>
<br>
<a href="http://graphicdesign.stackexchange.com/questions/4035/what-does-the-size-of-the-font-translate-to-exactly" rel="noreferrer" target="_blank">http://graphicdesign.stackexchange.com/questions/4035/what-does-the-size-of-the-font-translate-to-exactly</a><br>
<a href="https://www.tcl.tk/man/tcl8.4/TkCmd/font.htm#M26" rel="noreferrer" target="_blank">https://www.tcl.tk/man/tcl8.4/TkCmd/font.htm#M26</a><br>
<a href="https://www.tcl.tk/man/tcl8.4/TkCmd/tk.htm#M7" rel="noreferrer" target="_blank">https://www.tcl.tk/man/tcl8.4/TkCmd/tk.htm#M7</a><br>
<br>
I inferred that the height in pixels is a starting point from which to<br>
calculate the actual size for display. The font renderer may or may<br>
not reckon with display resolution and / or custom DPI setting to<br>
scale the font (with 72 DPI as reference).<br>
<br>
In Linux I used xzoom to count font pixels for a test. In<br>
xfce4-terminal and text editor Leafpad, DejaVu Sans Mono size 10 give<br>
14 pixels height and in Pd (on Xubuntu) the same font specs give 10<br>
pixels height (from highest ascender to lowest descender). My system<br>
DPI setting is 96 which is 1.333333 * 72. So terminal emulator and<br>
text editor do scaling while Pd does not. To me this seems the correct<br>
behavior for Pd because it doesn't scale non-text elements either.<br>
With system setting 72 DPI, font size 10 gives height 10 in terminal<br>
and text editor too - unscaled.<br>
<br>
But font size 12 gives 13 pixels height and size 16 gives 15 pixels<br>
height. So indeed there's not a strict 1:1 relation between font size<br>
and pixels even at 72 DPI. Maybe it is impossible to get proportions<br>
right at certain pixel heights. Anyhow the unscaled DejaVu Sans Mono<br>
is not way off it's nominal size in pixels.<br>
<span class=""><br>
><br>
> And keep in mind that on Tk you cannot control the spacing<br>
> between multiple lines of a canvas text item. I don't know<br>
> how that spacing is chosen, but if it's different from platform<br>
> to platform you're stuck.<br>
><br>
> Btw-- what does your patch look like on OSX?<br>
<br>
</span>I'll check tomorrow when I've access to a Mac.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Anyhow, the main problem is width as in your screenshots.<br>
> And pixel size-- even for the same font-- cannot guarantee<br>
> the same character width across platforms.<br>
><br>
> In both the current Pd-l2ork and the GUI port, the whole<br>
> font measuring algo is short circuited so you probably don't<br>
> run into this particular problem.<br>
><br>
> The current font-sizing algo is certainly too complex and<br>
> prone to error, and if you want to take a stab at improving it<br>
> I'm happy to test things. But this is really something that<br>
> has to be improved the _same_ way across all Pds.<br>
> Otherwise you're going to continue to see overlaps from<br>
> people who don't know what their patch looks like on your<br>
> machine.<br>
><br>
> -Jonathan<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Friday, October 9, 2015 5:14 AM, katja <<a href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>> wrote:<br>
><br>
><br>
> Hi Jonathan,<br>
><br>
> Considering the fact that IEM guis display with correct font size on<br>
> Raspbian, there must be a way to do it right. The difference between<br>
> IEM guis and object/message/comment is that in the first case you<br>
> specify font type and size explicitly, and a choice of available types<br>
> is presented according to platform. It is up to the patch developer to<br>
> select a font that is available on each platform if reproducible<br>
> appearance is important for the patch. For object/message/comment<br>
> instead, you can just select font size at patch creation time, not<br>
> font type.<br>
><br>
> Until a few days ago I knew little about font size, but I learned that<br>
> it is a pretty well-defined entity in DTP: the total number of pixels<br>
> from highest ascender till lowest descender in the character set for a<br>
> given font. For DejaVu Sans Mono, 'd' has the highest ascender and 'p'<br>
> has the lowest descender, therefore it is possible to check actual<br>
> font size by counting total pixel height in 'pd'. So it is only about<br>
> height, not width. Width of a word or line at a particular font size<br>
> can vary substantially according to font type. Also note that fonts in<br>
> some programs may be scaled through DPI settings, where 72 DPI is the<br>
> reference (while 96 DPI is default on Windows and Linux).<br>
><br>
> In a code editor for text-based computer languages you simply set a<br>
> monospace font to get an orderly appearance. Pd is more like a wysiwyg<br>
> markup language and code editor at the same time. Quite ambitious,<br>
> isn't it? It's remarkable how well it works most of the time across<br>
> platforms, particularly in Pd-extended. Pixel-precise cross-platform<br>
> appearance can only be achieved if monospace fonts with equivalent<br>
> height-width ratio are used, and font size is implemented literally<br>
> like it is probably done for the IEM guis.<br>
><br>
> Considering Pd as a markup language: a fundamental difference between<br>
> Pd and HTML is the way how elements are positioned (pixel coordinates<br>
> vs relative position of concatenated blocks). In HTML a block can grow<br>
> or shrink according to content, font size or font type, and push away<br>
> neighbor blocks. Pd elements can't do that, and scalable pixel<br>
> coordinates don't magically enable such behavior.<br>
><br>
> Katja<br>
><br>
><br>
> On Fri, Oct 9, 2015 at 4:39 AM, Jonathan Wilkes <<a href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>> wrote:<br>
>> Hi katja,<br>
>> What you say is completely reasonable. And according to Pd's source code,<br>
>> it also happens to be wrong.<br>
>><br>
>> Here's the definition of a size "10" font, from sys_fontlist of s_main.c:<br>
>> fi_fontsize = 10 (we don't know what the units are but I'm guessing it's<br>
>> supposed to be points)<br>
>> fi_maxwidth = 7 (pixels)<br>
>> fi_maxheight = 13 (pixels)<br>
>><br>
>> So according to Pd, a size "10" font is the largest font size<br>
>> listed that has a width no greater than 7 pixels and a height<br>
>> no greater than 13. (Unless _no_ font will fit in that spec in<br>
>> which case the smallest font size is used.) Pd doesn't care if the font<br>
>> is<br>
>> "Crazy Cursive Condensed" at size<br>
>> "33.3333pts". As long as that font fits the closest to the max<br>
>> height/width, it can be used for size "10".<br>
>><br>
>> Regardless of how the font metrics proc is picking that<br>
>> 11px font, it still fits the metrics Pd gives for a size "10" font.<br>
>> Even if we "fixed" this bug, any other user on any other OS<br>
>> can have a size "10" font with characters that measure 7x13<br>
>> pixels. And because it's ultimately up to the font engine<br>
>> exactly how the characters get rendered, such a user could<br>
>> even be using "DejaVu Sans Mono" and hit this<br>
>> discrepancy. They wouldn't know they hit it until they<br>
>> compared their screenshot to yours.<br>
>><br>
>> The only solution is to always render the box for the max<br>
>> width/height characters. That would almost be guaranteed<br>
>> to look ugly on everyone's system, but at least you'd be<br>
>> guaranteed never to accidentally create a patch where<br>
>> boxes overlap on someone else's machine.<br>
>><br>
>> I'll admit that in the GUI port I haven't addressed this<br>
>> problem.<br>
>><br>
>> -Jonathan<br>
>><br>
>><br>
>><br>
>><br>
>> On Thursday, October 8, 2015 8:20 PM, katja <<a href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> On Thu, Oct 8, 2015 at 3:41 PM, Jonathan Wilkes <<a href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>><br>
>> wrote:<br>
>>> Four things:<br>
>>> 1) The font dialog shouldn't use numbers. It should say "tiny", "small",<br>
>>> "medium", etc. because those numbers just mislead the user.<br>
>><br>
>> Numbers only mislead the user when the wrong font size is displayed,<br>
>> like on Raspbian (size 11 where 10 is requested, as revealed by your<br>
>> bugfinder code). Since objects are positioned at fixed coordinates in<br>
>> a Pd patch, and coordinates are given in pixels, it is required to<br>
>> define and register everything else in exact pixels too, in order to<br>
>> display patches undistorted across platforms and independent from DPI<br>
>> settings.<br>
>><br>
>> Attached are two zoomed screenshots where font pixels can be counted:<br>
>> 10 pix total height on Xubuntu and 11 on Raspbian, exactly the size as<br>
>> reported by Tk. Why Tk gives size 11 when Pd wants 10 I don't know but<br>
>> it is a bug and apart from the bug everything is totally accurate.<br>
>><br>
>><br>
>><br>
>>> 2) Font dialog number "10" in Vanilla may correspond to any font size<br>
>>> that<br>
>>> has<br>
>>> a width less than or equal to 7 pixels (and height <= 13). That includes<br>
>>> DejaVu Sans Mono at pixel size 11 on Raspbian. Since the text fits in<br>
>>> the<br>
>>> box in your screenshot we can tell Tk is measuring the actual font<br>
>>> correctly. (Well, more or<br>
>>> less-- what happens with a message box that has, say 50 lines?).<br>
>>><br>
>>> 3) I can't figure out how pd_font_10 ends up with pixel size "11".<br>
>>><br>
>>> 4) There are only two ways I can think of to fix this problem. One is to<br>
>>> always<br>
>>> size boxes according to fi_maxwidth and fi_maxheight. The other is to<br>
>>> forgo<br>
>>> the automated metrics and brute-force it so that DejaVu Sans Mono fits<br>
>>> exactly<br>
>>> into the hardcoded metrics of s_main.c. I chose the 2nd solution in the<br>
>>> GUI<br>
>>> port, but only because I have decimal pixel sizes to choose from. Tcl/tk<br>
>>> doesn't<br>
>>> let you do that.<br>
>>><br>
>>> I'll check again but I think my method looks fine on Raspbian as well as<br>
>>> Ubuntu.<br>
>>><br>
>>> I also played around with Droid Sans Mono Dotted because it has CJK<br>
>>> characters. But DejaVu Sans Mono evidently has them, too-- or at least<br>
>>> when<br>
>>> I copy/paste them they show up correctly. (Perhaps there's some kind of<br>
>>> fallback mechanism that I'm not seeing.) Those characters open up a<br>
>>> wellspring of new problems. They are referred to as "full width", but<br>
>>> take<br>
>>> up something like 1.5x width of ascii characters. If you use them in<br>
>>> any flavor of Pd they overflow the object/message box borders.<br>
>>><br>
>>> -Jonathan<br>
>>><br>
>>><br>
>>><br>
>>> On Thursday, October 8, 2015 2:53 AM, katja <<a href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>><br>
>>> On Thu, Oct 8, 2015 at 12:23 AM, Jonathan Wilkes <<a href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>><br>
>>> wrote:<br>
>>>> Ok, try this in place of the command that was giving the error:<br>
>>>> pdtk_post "rank tk speculation follows: [font actual [get_font_for_size<br>
>>>> $font_size] -displayof $tkcanvas]\n"<br>
>>>><br>
>>><br>
>>> There you got it, inspector Wilkes! For Xubuntu the output is:<br>
>>><br>
>>> rank tk speculation follows: -family {DejaVu Sans Mono} -size -10<br>
>>> -weight normal -slant roman -underline 0 -overstrike 0<br>
>>><br>
>>> For Raspbian:<br>
>>><br>
>>> rank tk speculation follows: -family {DejaVu Sans Mono} -size -11<br>
>>> -weight normal -slant roman -underline 0 -overstrike 0<br>
>>><br>
>>> In both cases the font size menu says "10".<br>
>>><br>
>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Wednesday, October 7, 2015 4:33 PM, Jonathan Wilkes via Pd-list<br>
>>>> <<a href="mailto:pd-list@lists.iem.at">pd-list@lists.iem.at</a>> wrote:<br>
>>>><br>
>>>><br>
>>>> Sorry, I thought that would work. I'll sit down and wade through all<br>
>>>> the<br>
>>>> indirection later to get a working debug printout.<br>
>>>><br>
>>>> -Jonathan<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Wednesday, October 7, 2015 4:26 PM, katja <<a href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>><br>
>>>> wrote:<br>
>>>><br>
>>>><br>
>>>> On Wed, Oct 7, 2015 at 9:40 PM, Jonathan Wilkes <<a href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>><br>
>>>> wrote:<br>
>>>>> For the official record-- I'm holding my tongue, in the hopes that when<br>
>>>>> others look at the code<br>
>>>>> in my GUI port they'll practice similar restraint.<br>
>>>>><br>
>>>>> Ok, add this:<br>
>>>>><br>
>>>>> pdtk_post "for real this time-- the actual font we are sending to tk<br>
>>>>> is:<br>
>>>>> [set [get_font_for_size $font_size]]\n"<br>
>>>><br>
>>>> Pd list is now looking at a line that doesn't work. The error is:<br>
>>>><br>
>>>> can't read "::pd_font_10": no such variable<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>>> -Jonathan<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Wednesday, October 7, 2015 3:19 PM, katja <<a href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>><br>
>>>>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>> On Wed, Oct 7, 2015 at 8:37 PM, Jonathan Wilkes <<a href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>><br>
>>>>> wrote:<br>
>>>>>> Silly me, I forgot this is Pd so it has to be way more complex than<br>
>>>>>> that...<br>
>>>>>><br>
>>>>>> Add this line to pdtk_text_new in pdtk_text.tcl:<br>
>>>>>><br>
>>>>>> pdtk_post "the actual font we are sending to tk is: [get_font_for_size<br>
>>>>>> $font_size]\n"<br>
>>>>>><br>
>>>>>> Now do the test I mentioned before.<br>
>>>>><br>
>>>>> The answer is in both cases:<br>
>>>>><br>
>>>>> "the actual font we are sending to tk is: ::pd_font_10"<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>>> -Jonathan<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Wednesday, October 7, 2015 2:16 PM, Jonathan Wilkes via Pd-list<br>
>>>>>> <<a href="mailto:pd-list@lists.iem.at">pd-list@lists.iem.at</a>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>> Hi katja,<br>
>>>>>><br>
>>>>>> Could you do a test? Make a simple patch with a single object in it,<br>
>>>>>> and<br>
>>>>>> use the same canvas font size you did above. Then run Pd with -d 3<br>
>>>>>> flag<br>
>>>>>> and<br>
>>>>>> see what font size is actually being sent from Pd to the GUI on each<br>
>>>>>> distro.<br>
>>>>>><br>
>>>>>> -Jonathan<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Wednesday, October 7, 2015 12:28 PM, katja <<a href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>><br>
>>>>>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>> Hello,<br>
>>>>>><br>
>>>>>> A particular font size issue can be observed in vanilla Pd and package<br>
>>>>>> puredata on Raspbian Wheezy and Jessie: font size 10 is larger for<br>
>>>>>> object boxes, message boxes and comments than for IEM guis (bang,<br>
>>>>>> toggle, slider, radio button, canvas). Object/message/comment<br>
>>>>>> characters are too large in number of pixels. When Edit > Font > Font<br>
>>>>>> Size is set to 8, their size is identical to IEM gui font size 10.<br>
>>>>>> This inconsistency does not happen for me on Xubuntu. A test patch and<br>
>>>>>> two screenshots are attached for illustration.<br>
>>>>>><br>
>>>>>> For IEM guis, font size 10 translates to 6 pixels per character on<br>
>>>>>> both systems, given the default font type DejaVu Sans Mono. For object<br>
>>>>>> boxes, message boxes and comments, font size 10 is 6 pixels on Xubuntu<br>
>>>>>> and almost 7 pixels on Raspbian.<br>
>>>>>><br>
>>>>>> I don't know if this issue is related to font size effects on Windows<br>
>>>>>> as described by Roman in another thread. In any case, consequences are<br>
>>>>>> similar: patches created on Xubuntu tend to look messy on Raspbian,<br>
>>>>>> sometimes with overlapping texts. With XFCE (Xubuntu's default desktop<br>
>>>>>> environment) installed on Raspbian the issue still persists. Custom<br>
>>>>>> dpi setting has no effect on Pd. What else might cause the difference<br>
>>>>>> in behavior on those systems?<br>
>>>>>><br>
>>>>>> Katja<br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
>>>>>> UNSUBSCRIBE and account-management -><br>
>>>>>> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
>>>>>> UNSUBSCRIBE and account-management -><br>
>>>>>> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
>>>>>><br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
>>>> UNSUBSCRIBE and account-management -><br>
>>>> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
>>>><br>
>>>><br>
>>><br>
>>><br>
>><br>
>><br>
><br>
><br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br></div>