Re: Announce: tkpath 0.2


Hello,

tkpath seems like a very nice addition to Tk.

Currently, in order to print on Windows, one can use the
"print" package for dealing with the printer and the "gdi" package
for drawing (both developed by Michael I. Schwartz). The "gdi" package
only permmits very simple drawing. Would it be possible to use tkpath
in order to draw for printing? Would it have a command to print text
with all the unicode chars?


Ramon Ribó

En Mon, 17 Jul 2006 10:10:33 +0200, <matsben@xxxxxxxxx> escribió:


Roy Terry skrev:

Is anti-aliased text on demand a possibility?


I haven't yet bothered thinking about text.

> The core part is the path item which is very flexible. For items that
> are
> similar to existing canvas items I have prepended the names with a "p".

Perhaps you would consider adding the leading 'p' in all cases
to ease the memory load when mixing conventional and tkpath-based
canvas items. If tkpath items were being added to existing canvas
code it seems one could easily forget that "oval" was native to the
canvas and elllipse was xpath. I suggest having the leading 'p'
in all cases will be most helpful (pcircle, pellipse).

Maybe.


A lot more path-based items. 0.1 only
had paths!
I'm curious, aside from compactness, does
drawing a rect with 'prect" offer advantages to
drawing it with 'path'? Same question for other
shapes.

I'm trying to pick "native" APIs if they can be used.
A prect with no radius draws using native Rect API in most cases,
while if rounded I construct it using paths internally only.
Circle/ellipse are always using native APIs for drawing.


Feature suggestion: Any chance of
being able to set anti-alias on a per-item
basis (over-riding the default)? Some items
at small sizes just look better without it.

See my note about pixel alignment which may help.
I'm not so fond of your idea.

Looking at the doc/readme, it lists the options
for items but still says "not all are implemented".
Would be nice if you could mark which ones do
work as sometimes I'm not sure if an option is
not implemented or my setting is wrong.

It is the -*stipple -*offset ones that are unimplemented.
Maybe I optimistically added -strokegradient to the code
but that is also unimplemented. Not sure how -state is supposed to
work.


I am using the 0.1 binary with Tcl/Tk 8.4.9 on xp and w2000.
Will the 0.2 binary work with those versions too?


Hopefully ;-)

Mats




--
Compass Ing. y Sistemas Dr. Ramon Ribo
http://www.compassis.com ramsan@xxxxxxxxxxxxx
c/ Tuset, 8 7-2 tel. +34 93 218 19 89
08006 Barcelona, Spain fax. +34 93 396 97 46
.

Relevant Pages

  • Re: Tcl & Cairo
    ... tkpath has high level bindings ... and it currently only creates new canvas items. ... ttk element for custom drawing. ...
    (comp.lang.tcl)
  • Re: Announce: tkpath 0.2
    ... This package implements path drawing modelled after its SVG ... similar to existing canvas items I have prepended the names with a "p". ... If tkpath items were being added to existing canvas ...
    (comp.lang.tcl)
  • ANNOUNCE: tkpath 0.2.4
    ... Tkpath is an extension package to Tcl/Tk that provides much improved ... New tkpath::surface command which creates in memory drawing ... Empty gradient -stops ... My Coccinella sources contain a SVG importer that can handle some SVG ...
    (comp.lang.tcl)
  • Re: ANNOUNCE: tkpath 0.1
    ... > This is the first release of the tkpath extension package to Tcl/Tk. ... > The package implements path drawing modelled after its SVG counterpart, ... > It is very flexible and reproduces all standard drawing canvas items. ...
    (comp.lang.tcl)
  • Re: Announce: tkpath 0.2
    ... tkpath seems like a very nice addition to Tk. ... Currently, in order to print on Windows, one can use the ... only permmits very simple drawing. ... general and x-platform way of printing where I essentially have ...
    (comp.lang.tcl)