On Fri, Oct 9, 2015 at 4:42 PM, Jonathan Wilkes <jancsika@yahoo.com> wrote:
> The patch developer can't get reproducible appearance
> with iemguis across platforms:
> * the patch developer is almost never able to know what
> fonts are available on the other platforms
> * the patch developer can't know the actual metrics of
> the font on those platforms
> * there's nothing in the iemgui properties that tells the user
> the first font in the list is supposed to be guaranteed to exist
> on all platforms (and is supposed to be DejaVu Sans Mono), and that the
> other two may vary

True, there can't be a guarantee, patches have to be tested on all
platforms but with Pd-extended I was able to get almost uniform
appearance across platforms.

>
> Where do you get your information for how a pixel-size font
> is defined?  I've never seen anything written or tested that
> to conclude that if I pick "10px" as my font size the font
> engine _must_ render the font exactly 10 pixels from
> ascender to descender.

Some bits:

http://graphicdesign.stackexchange.com/questions/4035/what-does-the-size-of-the-font-translate-to-exactly
https://www.tcl.tk/man/tcl8.4/TkCmd/font.htm#M26
https://www.tcl.tk/man/tcl8.4/TkCmd/tk.htm#M7

I inferred that the height in pixels is a starting point from which to
calculate the actual size for display. The font renderer may or may
not reckon with display resolution and / or custom DPI setting to
scale the font (with 72 DPI as reference).

In Linux I used xzoom to count font pixels for a test. In
xfce4-terminal and text editor Leafpad, DejaVu Sans Mono size 10 give
14 pixels height and in Pd (on Xubuntu) the same font specs give 10
pixels height (from highest ascender to lowest descender). My system
DPI setting is 96 which is 1.333333 * 72. So terminal emulator and
text editor do scaling while Pd does not. To me this seems the correct
behavior for Pd because it doesn't scale non-text elements either.
With system setting 72 DPI, font size 10 gives height 10 in terminal
and text editor too - unscaled.

But font size 12 gives 13 pixels height and size 16 gives 15 pixels
height. So indeed there's not a strict 1:1 relation between font size
and pixels even at 72 DPI. Maybe it is impossible to get proportions
right at certain pixel heights. Anyhow the unscaled DejaVu Sans Mono
is not way off it's nominal size in pixels.

>
> And keep in mind that on Tk you cannot control the spacing
> between multiple lines of a canvas text item.  I don't know
> how that spacing is chosen, but if it's different from platform
> to platform you're stuck.
>
> Btw-- what does your patch look like on OSX?

I'll check tomorrow when I've access to a Mac.

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

>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pd-list@lists.iem.at mailing list
>>>>>> UNSUBSCRIBE and account-management ->
>>>>>> http://lists.puredata.info/listinfo/pd-list
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pd-list@lists.iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> http://lists.puredata.info/listinfo/pd-list
>>>>
>>>>
>>>
>>>
>>
>>
>
>

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list