Announce: tkpath 0.2
mat...@gmail.com
ANNOUNCE tkpath version 0.2
---------------------------
This package implements path drawing modelled after its SVG
counterpart,
see http://www.w3.org/TR/SVG11/.
It contains replacements for all canvas drawing items except for the
text item.
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".
The items are:
path
prect
circle
ellipse
pline
polyline
ppolygon
pimage
They are typically much more flexible than their canvas counterparts.
Some features:
antialiasing
affine transforms
opacity
linear gradients
radial gradients
It is also possible to define styles to be used for sets of items.
This is in line with modern design patterns that separate the apperance
from
the content.
Home: http://tclbitprint.sourceforge.net/
This package is simplest described using screenshots:
http://tclbitprint.sourceforge.net/tkpath/quartz/index.html
http://tclbitprint.sourceforge.net/tkpath/gdiplus/index.html
http://tclbitprint.sourceforge.net/tkpath/cairo/index.html
There are five backends used for drawing. They are all platform
specific
except for the Tk drawing which uses only the API found in Tk.
It is only to be used as a fallback when the cairo backend is missing.
The backends:
1) CoreGraphics for MacOSX, built using ProjectBuilder
2) GDI for Win32, built by VC++7 (.NET)
3) GDI+ for WinXP, built by VC++7 (.NET), runs also on older system
using the gdiplus.dll
4) cairo (http://cairographics.org), built using the automake
system;
the configure.in and Makefile.in files are a hack, so please
help
yourself (and me). It requires a cairo 1.0 installation since
incompatible API changes appeared before 1.0 (libcairo.so.2 ?).
5) Tk drawing, fallback for cairo mainly, very basic
BSD style license.
Enjoy, Mats (mat...@users.sourceforge.net)
Roy Terry
news:1153035655.9...@75g2000cwc.googlegroups.com...
>
> ANNOUNCE tkpath version 0.2
> ---------------------------
Mats, It's great to see you're still enhancing
this package. It makes a substantial visual
improvement to my Tk apps.
>
> This package implements path drawing modelled after its SVG
> counterpart,
> see http://www.w3.org/TR/SVG11/.
>
> It contains replacements for all canvas drawing items except for the
> text item.
Is anti-aliased text on demand a possibility?
> 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).
> The items are:
>
> path
> prect
> circle
> ellipse
> pline
> polyline
> ppolygon
> pimage
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.
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.
>
> They are typically much more flexible than their canvas counterparts.
> Some features:
>
> antialiasing
> affine transforms
> opacity
> linear gradients
> radial gradients
Radial gradients I think are new. Very cool.
>
> It is also possible to define styles to be used for sets of items.
> This is in line with modern design patterns that separate the apperance
> from
> the content.
>
> Home: http://tclbitprint.sourceforge.net/
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.
>
> This package is simplest described using screenshots:
> http://tclbitprint.sourceforge.net/tkpath/quartz/index.html
> http://tclbitprint.sourceforge.net/tkpath/gdiplus/index.html
> http://tclbitprint.sourceforge.net/tkpath/cairo/index.html
>
> There are five backends used for drawing. They are all platform
> specific
> except for the Tk drawing which uses only the API found in Tk.
> It is only to be used as a fallback when the cairo backend is missing.
>
> The backends:
>
> 1) CoreGraphics for MacOSX, built using ProjectBuilder
>
> 2) GDI for Win32, built by VC++7 (.NET)
>
> 3) GDI+ for WinXP, built by VC++7 (.NET), runs also on older system
> using the gdiplus.dll
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?
>
> 4) cairo (http://cairographics.org), built using the automake
> system;
> the configure.in and Makefile.in files are a hack, so please
> help
> yourself (and me). It requires a cairo 1.0 installation since
> incompatible API changes appeared before 1.0 (libcairo.so.2 ?).
>
> 5) Tk drawing, fallback for cairo mainly, very basic
>
> BSD style license.
>
> Enjoy, Mats (mat...@users.sourceforge.net)
Great work and much appreciated!
Roy Terry
>
mat...@gmail.com
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
Ramon Ribó
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ó
--
Compass Ing. y Sistemas Dr. Ramon Ribo
http://www.compassis.com ram...@compassis.com
c/ Tuset, 8 7-2 tel. +34 93 218 19 89
08006 Barcelona, Spain fax. +34 93 396 97 46
mat...@gmail.com
Ramon Ribó skrev:
> 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?
>
This is why I wrote the tclbitprint package that is supposed to be a
more
general and x-platform way of printing where I essentially have
rewritten
the canvas widget to draw on a user defined graphics device.
Currently I only have MacCarbonPrint for MacOSX but it shouldn't be
too difficult to write the windows printing stuff.
All drawing is already there using tk drawing in the canvas.
When tkpath gets more mature I can add also this code to tclbitprint.
The gdi package isn't very smart since it is completely tied to GDI
drawing.
Mats
Ramon Ribó
Thanks for the answer.
Do you have any plans on when it could happen, to
be able to print with all tkpath capabilities on
Windows?
Ramon Ribó
--
mat...@users.sourceforge.net
Ramon Ribó skrev:
> Thanks for the answer.
>
> Do you have any plans on when it could happen, to
> be able to print with all tkpath capabilities on
> Windows?
>
I don't have any plans to do this in the nearest future.
Mats