<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_1444431111471_14872">Coincidentally enough, I made a parody website on grid fonts to elucidate some of their obvious drawbacks:</div><div id="yui_3_16_0_1_1444431111471_15277"><a id="yui_3_16_0_1_1444431111471_15286" href="http://cogsci.indiana.edu/gridfonts.html">http://cogsci.indiana.edu/gridfonts.html</a></div><div id="yui_3_16_0_1_1444431111471_15288"><br></div><div id="yui_3_16_0_1_1444431111471_15308">-Jonathan<br></div><div id="yui_3_16_0_1_1444431111471_15317"><br></div><div class=".yiv8071630116yahoo_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 8:05 PM, Matt Barber <brbrofsvl@gmail.com> wrote:<br clear="none"> </font> </div>  <br clear="none"><br clear="none"> <div class="yiv8071630116y_msg_container"><div id="yiv8071630116"><div><div dir="ltr"><div class="yiv8071630116gmail_default" style="font-family:verdana, sans-serif;">Maybe we should design a Pd gridfont (see <a rel="nofollow" shape="rect" target="_blank" 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="yiv8071630116gmail_extra"><br clear="none"><div class="yiv8071630116gmail_quote">On Fri, Oct 9, 2015 at 7:42 PM, katja <span dir="ltr"><<a rel="nofollow" shape="rect" ymailto="mailto:katjavetter@gmail.com" target="_blank" href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>></span> wrote:<br clear="none"><blockquote class="yiv8071630116gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><span class="yiv8071630116">On Fri, Oct 9, 2015 at 4:42 PM, Jonathan Wilkes <<a rel="nofollow" shape="rect" ymailto="mailto:jancsika@yahoo.com" target="_blank" href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>> wrote:<br clear="none">
> The patch developer can't get reproducible appearance<br clear="none">
> with iemguis across platforms:<br clear="none">
> * the patch developer is almost never able to know what<br clear="none">
> fonts are available on the other platforms<br clear="none">
> * the patch developer can't know the actual metrics of<br clear="none">
> the font on those platforms<br clear="none">
> * there's nothing in the iemgui properties that tells the user<br clear="none">
> the first font in the list is supposed to be guaranteed to exist<br clear="none">
> on all platforms (and is supposed to be DejaVu Sans Mono), and that the<br clear="none">
> other two may vary<br clear="none">
<br clear="none">
</span>True, there can't be a guarantee, patches have to be tested on all<br clear="none">
platforms but with Pd-extended I was able to get almost uniform<br clear="none">
appearance across platforms.<br clear="none">
<span class="yiv8071630116"><br clear="none">
><br clear="none">
> Where do you get your information for how a pixel-size font<br clear="none">
> is defined?  I've never seen anything written or tested that<br clear="none">
> to conclude that if I pick "10px" as my font size the font<br clear="none">
> engine _must_ render the font exactly 10 pixels from<br clear="none">
> ascender to descender.<br clear="none">
<br clear="none">
</span>Some bits:<br clear="none">
<br clear="none">
<a rel="nofollow" shape="rect" target="_blank" href="http://graphicdesign.stackexchange.com/questions/4035/what-does-the-size-of-the-font-translate-to-exactly">http://graphicdesign.stackexchange.com/questions/4035/what-does-the-size-of-the-font-translate-to-exactly</a><br clear="none">
<a rel="nofollow" shape="rect" target="_blank" href="https://www.tcl.tk/man/tcl8.4/TkCmd/font.htm#M26">https://www.tcl.tk/man/tcl8.4/TkCmd/font.htm#M26</a><br clear="none">
<a rel="nofollow" shape="rect" target="_blank" href="https://www.tcl.tk/man/tcl8.4/TkCmd/tk.htm#M7">https://www.tcl.tk/man/tcl8.4/TkCmd/tk.htm#M7</a><br clear="none">
<br clear="none">
I inferred that the height in pixels is a starting point from which to<br clear="none">
calculate the actual size for display. The font renderer may or may<br clear="none">
not reckon with display resolution and / or custom DPI setting to<br clear="none">
scale the font (with 72 DPI as reference).<br clear="none">
<br clear="none">
In Linux I used xzoom to count font pixels for a test. In<br clear="none">
xfce4-terminal and text editor Leafpad, DejaVu Sans Mono size 10 give<br clear="none">
14 pixels height and in Pd (on Xubuntu) the same font specs give 10<br clear="none">
pixels height (from highest ascender to lowest descender). My system<br clear="none">
DPI setting is 96 which is 1.333333 * 72. So terminal emulator and<br clear="none">
text editor do scaling while Pd does not. To me this seems the correct<br clear="none">
behavior for Pd because it doesn't scale non-text elements either.<br clear="none">
With system setting 72 DPI, font size 10 gives height 10 in terminal<br clear="none">
and text editor too - unscaled.<br clear="none">
<br clear="none">
But font size 12 gives 13 pixels height and size 16 gives 15 pixels<br clear="none">
height. So indeed there's not a strict 1:1 relation between font size<br clear="none">
and pixels even at 72 DPI. Maybe it is impossible to get proportions<br clear="none">
right at certain pixel heights. Anyhow the unscaled DejaVu Sans Mono<br clear="none">
is not way off it's nominal size in pixels.<br clear="none">
<span class="yiv8071630116"><br clear="none">
><br clear="none">
> And keep in mind that on Tk you cannot control the spacing<br clear="none">
> between multiple lines of a canvas text item.  I don't know<br clear="none">
> how that spacing is chosen, but if it's different from platform<br clear="none">
> to platform you're stuck.<br clear="none">
><br clear="none">
> Btw-- what does your patch look like on OSX?<br clear="none">
<br clear="none">
</span>I'll check tomorrow when I've access to a Mac.<br clear="none">
<div class="yiv8071630116HOEnZb"><div class="yiv8071630116h5"><br clear="none">
><br clear="none">
> Anyhow, the main problem is width as in your screenshots.<br clear="none">
> And pixel size-- even for the same font-- cannot guarantee<br clear="none">
> the same character width across platforms.<br clear="none">
><br clear="none">
> In both the current Pd-l2ork and the GUI port, the whole<br clear="none">
> font measuring algo is short circuited so you probably don't<br clear="none">
> run into this particular problem.<br clear="none">
><br clear="none">
> The current font-sizing algo is certainly too complex and<br clear="none">
> prone to error, and if you want to take a stab at improving it<br clear="none">
> I'm happy to test things.  But this is really something that<br clear="none">
> has to be improved the _same_ way across all Pds.<br clear="none">
> Otherwise you're going to continue to see overlaps from<br clear="none">
> people who don't know what their patch looks like on your<br clear="none">
> machine.<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 Friday, October 9, 2015 5:14 AM, katja <<a rel="nofollow" shape="rect" ymailto="mailto:katjavetter@gmail.com" target="_blank" href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>> wrote:<br clear="none">
><br clear="none">
><br clear="none">
> 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">
><br clear="none">
> On Fri, Oct 9, 2015 at 4:39 AM, Jonathan Wilkes <<a rel="nofollow" shape="rect" ymailto="mailto:jancsika@yahoo.com" target="_blank" href="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<br clear="none">
>> 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 rel="nofollow" shape="rect" ymailto="mailto:katjavetter@gmail.com" target="_blank" href="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 rel="nofollow" shape="rect" ymailto="mailto:jancsika@yahoo.com" target="_blank" href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>><br clear="none">
>> 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<br clear="none">
>>> 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 rel="nofollow" shape="rect" ymailto="mailto:katjavetter@gmail.com" target="_blank" href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>><br clear="none">
>>> wrote:<br clear="none">
>>><br clear="none">
>>><br clear="none">
>>> On Thu, Oct 8, 2015 at 12:23 AM, Jonathan Wilkes <<a rel="nofollow" shape="rect" ymailto="mailto:jancsika@yahoo.com" target="_blank" href="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 rel="nofollow" shape="rect" ymailto="mailto:pd-list@lists.iem.at" target="_blank" href="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<br clear="none">
>>>> 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 rel="nofollow" shape="rect" ymailto="mailto:katjavetter@gmail.com" target="_blank" href="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 rel="nofollow" shape="rect" ymailto="mailto:jancsika@yahoo.com" target="_blank" href="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<br clear="none">
>>>>> 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 rel="nofollow" shape="rect" ymailto="mailto:katjavetter@gmail.com" target="_blank" href="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 rel="nofollow" shape="rect" ymailto="mailto:jancsika@yahoo.com" target="_blank" href="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 rel="nofollow" shape="rect" ymailto="mailto:pd-list@lists.iem.at" target="_blank" href="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 rel="nofollow" shape="rect" ymailto="mailto:katjavetter@gmail.com" target="_blank" href="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 rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="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 rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><div class="qtdSeparateBR"><br><br></div><div class="yiv8071630116yqt9427512385" id="yiv8071630116yqtfd67052"><br clear="none">
>>>>>><br clear="none">
>>>>>><br clear="none">
>>>>>><br clear="none">
>>>>>> _______________________________________________<br clear="none">
>>>>>> <a rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="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 rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">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 rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="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 rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">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">
<br clear="none">
_______________________________________________<br clear="none">
<a rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">
UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
</div></div></div></blockquote></div><div class="yiv8071630116yqt9427512385" id="yiv8071630116yqtfd64685"><br clear="none"></div></div></div></div><br clear="none"><br clear="none"></div>  </div> </div>  </div></div></body></html>