Current standard:
* all boxes have the same top-left origin
Current nonstandards:
* font size
* font face
* box length, thus ancillary xlet positions
* box height
So the only thing anyone can expect from the current behavior is that they can
connect the left outlet of [foo] to the left inlet of [bar] and get a straight
line that is straight across platforms. Everything in a Pd diagram aside from
iemgui polygons and left xlets is subject to random variation.
Since font size can _never_ be guaranteed to be pixel exact, Pd diagrams should
hard code the box sizes so that they can be cross platform. I've checked font
metrics for "DejaVu Sans Mono" with the attached script on winxp and fedora at
various DPI and screen resolutions, and the font-rendering variations I get are
within a pixel. So we could choose the largest values for the font's
linespace and character width to virtually guarantee that, say, a size -12
"DejaVu Sans Mono" font will fit in the box on any platform. In other words,
the user chooses a box size instead of a font size.
This has the benefit of working with system fonts and custom fonts-- you just
have a font init loop that increments the font size until it finds the largest
size that fits in the hardcoded rectangle without overlapping it. As a result,
all straight line connections will remain straight lines-- in fact, the entire
Pd diagram will be exact across platforms, save for font faces, or small
variations in font size.
-Jonathan
>________________________________
>From: Hans-Christoph Steiner <[email protected]>
>To: Stephen Lavelle <[email protected]>
>Cc: pd-dev List <[email protected]>
>Sent: Monday, August 22, 2011 12:04 PM
>Subject: Re: [PD-dev] Status of GUI rewrite?
>
>
>On Aug 22, 2011, at 8:50 AM, Stephen Lavelle wrote:
>
>>> You can increase the font size which will make the boxes bigger. Also, you
>>> might like the new inlet/outlet highlighting that's in Pd-extended 0.43 and
>>> pd-l2ork. The inlets and outlets are tagged using Tk tags, so you should
>>> be able to change their size using the Tk canvas commands 'coords' or
>>> 'itemconfigure -width', etc. I've never tried tho.
>>> Their hitboxes aren't though - canvas_doclick in g_editor.c has hard-coded
>>> numbers.
>>
>> Arg, yes, that's true... sigh... but I find the inlet/outlet highlighting
>> helps a lot.
>>
>> If I were to try make a patch, what do you think the appropriate place to
>> expose it? It feels like it would sit well beside the font size options...
>
>
>If you're modifying the C code, then I think the best approach would be to
>expose the settings in a way that people could change them via Tcl i.e. a GUI
>plugin. Then people can play around with all sorts of behaviors. Its going to
>be the kind of thing where it'll be difficult to change the existing behavior
>because so many people expect it to work like that. So it needs to be
>something customizable.
>
>.hc
>
>----------------------------------------------------------------------------
>
>Using ReBirth is like trying to play an 808 with a long stick. -David
>Zicarelli
>
>
>
>_______________________________________________
>Pd-dev mailing list
>[email protected]
>http://lists.puredata.info/listinfo/pd-dev
>
>
>
package require Tk 8.5
canvas .c
set display_font {DejaVu Sans Mono}
set xoffset 25
set yoffset 10
set msg "Hello Woyld"
set font {DejaVu Sans Mono}
foreach size {8 10 12 14 16 18 20 22 24} {
set size [expr {$size * -1}]
set rectx2 [expr {[font measure [list $font $size] m] * [string length $msg] + $xoffset + 1}]
set recty2 [expr {[font metrics [list $font $size] -linespace ] + $yoffset} + 2]
.c create text 1 $yoffset -anchor nw -text $size
.c create rectangle $xoffset $yoffset $rectx2 $recty2
set metrics [font metrics [list $font $size]]
set measure [font measure [list $font $size] m]
.c create text [expr {$xoffset + 1}] [expr {$yoffset + 1}] -anchor nw -text $msg -font [list $display_font $size]
.c create text 185 $yoffset -anchor nw -text "[format m=%spx $measure]"
.c create text 240 $yoffset -anchor nw -text $metrics
puts $measure
incr yoffset 30
}
pack .c
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
