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