Obstacles for Tcl/Tk commercial application development ?
Bugs
development? Any folks here with experience in this area???
What things in particular made it a challenge to use Tcl/Tk to develop a
commercial application?
e.g. Licensing, distribution, lack of printing support, etc.
Thanks!
Bryan Oakley
Lack of a good printing is a big problem. There's simply no easy
solution; Tk is still in the 80's in this regard.
Robert Hicks
Is that because of the nature of the canvas widget? Or just that
nobody has focused on
that area of Tk?
Robert
Gerald W. Lester
> What obstacles are there to using Tcl/Tk for commercial application
> development?
Very few if any.
> Any folks here with experience in this area???
Yes, have used it in several fairly large commercial applications since the
early 90s.
> What things in particular made it a challenge to use Tcl/Tk to develop a
> commercial application?
>
> e.g. Licensing, distribution, lack of printing support, etc.
Licensing and distribution are non-issues.
A platform independent printing solution is non-existent. However many
commercial applications can make use of a platform specific solution.
Many people feel, for some strange reason, to tell clients that their
product is written in Tcl/Tk. Since it is not one of the current buzz words
some "management" types have problem with that. My solution has always been
to say it is our software and none of their business -- politely of course.
Interesting enough, the only other language that people seem to insist on
saying their applications are in is Java -- because it is a buzz word and
they hope that people will buy it for the Java label and ignore the
shortcomings.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Darren New
> What obstacles are there to using Tcl/Tk for commercial application
> development?
I think you're going to get a lot of different answers depending on what
kind of application you're talking about. Kiosk? Desktop? Dedicated
hardware? Server/Service?
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
Bugs
> Bugs wrote:
>> What obstacles are there to using Tcl/Tk for commercial application
>> development?
>
> I think you're going to get a lot of different answers depending on what
> kind of application you're talking about. Kiosk? Desktop? Dedicated
> hardware? Server/Service?
>
Desktop.
Kevin Walzer
I don't think there are any special challenges to using Tcl/Tk for
commercial development--they are similar to using any other toolkit. I
use Tcl/Tk for two of my three programs, and have not encountered any
huge barriers to my work. Of course, commercial deveopment involves many
other aspects, such as marketing, that have little or nothing to do with
your choice of languages but which play a huge role in your success or
failure.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Torsten Berg
> distribution,
This can be tricky. Source code protection is definitely an issue
which does not come out of the box in Tcl. But there are solutions for
all needs, ranging from obfuscation to byte compiling to encryption.
> lack of printing support
There is no cross-platform solution for this (perhaps apart from
tclbitprint), which may be an obstacle to software trying to be the
same across platforms. And it is not only the canvas, as Robert
mentioned, it is also the text widget and perhaps some tables (from
tktable or tablelist) that would need printing support.
But all in all, there's nearly nothing you cannot do in Tcl for
commercial applications!
Torsten
Eckhard Lehmann
> > distribution,
>
> This can be tricky. Source code protection is definitely an issue
> which does not come out of the box in Tcl. But there are solutions for
> all needs, ranging from obfuscation to byte compiling to encryption.
Isn't byte code compiling the same as obfuscating, the same as
"encryption" in Tcl - and all of this can be done with TclDevKit?
>
> > lack of printing support
agreed, this is really an issue. Is there a TIP for improving printer
support? It would involve quite a lot of work, but it's definitely
worth it. I've often stumbled over this issue in the past.
Imho, every Tk widget should get it's own "print" subcommand that
takes care of all the internals to pretty layout itself and it's
contents on paper (or pdf, or whatever).
Synic
On a technical and legal level, very few. Tcl/Tk is a mature language
which is readily extensible as need be. Its license (and the license
chosen by the majority of extension authors) is BSD, which is friendly
to commercial and noncommercial developers alike.
> What things in particular made it a challenge to use Tcl/Tk to develop a
> commercial application?
Mostly it's just mind-share thing among the IT management class. Tcl is
paying the price for all those years telling people that attractive
widgets didn't matter if it was functional, I suspect. It allowed
the language to look dated and dowdy to casual observers.
Robert Heller
>
>
> > distribution,
>
> This can be tricky. Source code protection is definitely an issue
> which does not come out of the box in Tcl. But there are solutions for
> all needs, ranging from obfuscation to byte compiling to encryption.
>
> > lack of printing support
>
> There is no cross-platform solution for this (perhaps apart from
> tclbitprint), which may be an obstacle to software trying to be the
> same across platforms. And it is not only the canvas, as Robert
> mentioned, it is also the text widget and perhaps some tables (from
> tktable or tablelist) that would need printing support.
The main obstacle to a cross-platform solution for printing is
MS-Windows itself -- in a sense, MS-Windows has pretty 'rotten'
printing support in general. Both UNIX/Linux and MacOSX have CUPS or at
least lpd and support PostScript as a standard medium for printing.
That is, you just need to generate PostScript and the print sub-system
takes it from there.
While it would be nice to have a 'postscript' subcommand for text
widgets, it is not terribly essentual, since it is not too hard to just
transfer the text (with attributes) from a text widget to a canvas
widget. I don't know about tktable or tablelist, but it *should* be
possible to again transfer the contents of a tktable or tablelist widget
to a canvas widget and print from there.
>
> But all in all, there's nearly nothing you cannot do in Tcl for
> commercial applications!
>
> Torsten
>
--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Larry W. Virden
I've seen numerous commercial applications announced on comp.lang.tcl
over its 18 years. So certainly it is doable.
Some of the challenges that are commonly discussed include:
a. dealing with the fact that, by default, if the application is just
tcl code, it is plain text that is interpreted, resulting in a variety
of attempts to keep users from either changing the code (causing
problems that the sellers then have to deal with) or "stealing" the
code. Some of the solutions include byte compiling, obfuscation,
creating C code calls for much of the functionality, and I've seen
discussions about encrypting/decrypting pieces, etc. Many of these
"solutions" bring in their own set of issues - performance, etc.
b. dealing with license management - again, this is an area that
people end up developing for themselves, resulting in of course even
more code to debug and maintain.
c. printing - providing for the user a method of generating a hard
copy of information being displayed
Additionally, while I don't recall seeing a lot of discussion on the
topic, I suspect that debugging applications that are running in a
"foreign" environment (ie the user's desktop or server environment) is
probably pretty tough. But that is true for any commercial product.
Another is just the challenge of practicing good software engineering,
with documentation, source control, etc. Again, this is not unique to
Tcl - no matter what language you use, these are issues to address.
Arndt Roger Schneider
CAIRO.
The Xlib emulation layer should being slashed
and Tk must move to Cairo (windows and Aqua, too).
pdf is just another backend in cairo --printing done.
-roger
Darren New
> The main obstacle to a cross-platform solution for printing is
> MS-Windows itself -- in a sense, MS-Windows has pretty 'rotten'
> printing support in general. Both UNIX/Linux and MacOSX have CUPS or at
> least lpd and support PostScript as a standard medium for printing.
> That is, you just need to generate PostScript and the print sub-system
> takes it from there.
Isn't it the case that in Windows, it's primarily a matter of using the
same graphics primitives for the printer that you do for the screen?
There's no need to generate a different form for printing (postscript)
than for display. You basically open a printer context (as you would
open a window) and draw into that what you want each time you're asked
to generate a page. You have to do the pagination yourself and
scale/wrap to fit the page size and all, but you have to do that with
postscript too. I'm not sure what the problem is, other than maybe Tk
using an X emulation layer that makes it difficult.
Kevin Walzer
> CAIRO.
>
> The Xlib emulation layer should being slashed
> and Tk must move to Cairo (windows and Aqua, too).
>
> pdf is just another backend in cairo --printing done.
>
> -roger
Except that Cairo only ships by default on Linux, yes? That wouldn't
work on Aqua. I thought one of the major reasons for Tk's portability is
that it hooks into the native windowing system on each platform.
Robert Heller
>
> Robert Heller wrote:
> > The main obstacle to a cross-platform solution for printing is
> > MS-Windows itself -- in a sense, MS-Windows has pretty 'rotten'
> > printing support in general. Both UNIX/Linux and MacOSX have CUPS or at
> > least lpd and support PostScript as a standard medium for printing.
> > That is, you just need to generate PostScript and the print sub-system
> > takes it from there.
>
> Isn't it the case that in Windows, it's primarily a matter of using the
> same graphics primitives for the printer that you do for the screen?
> There's no need to generate a different form for printing (postscript)
> than for display. You basically open a printer context (as you would
> open a window) and draw into that what you want each time you're asked
> to generate a page. You have to do the pagination yourself and
> scale/wrap to fit the page size and all, but you have to do that with
> postscript too. I'm not sure what the problem is, other than maybe Tk
> using an X emulation layer that makes it difficult.
The UNIX/Linux system does not have a 'graphics primitives for the
printer' API (as far as I know). UNIX systems (and Linix) use X11 for
graphics and generally X11 does not directly implement printer support.
Under UNIX (where Tcl/Tk came from), hard copy output is done via
postscript. The canvas widget defines a postscript 'driver' function
for each graphical primitive, as well as a screen (X11) 'driver'
function. Then the generated postscript is sent (via lp/lpr) to the
printer. This works for MacOSX as well, since MacOSX also has the
lp/lpr commands like any other UNIX or UNIX-like system.
There are some important differences between printing and displaying,
not the least of which is things like pagination.
Derek Fountain
> commercial application?
Something no one has mentioned as yet is the attitude of developers
towards the language. If you're doing your own development this won't be
an issue, but if your hoping to employ people it might.
First, Tcl developers are in much shorter supply than Perl or Java guys.
You might have trouble recruiting.
Second, you might have trouble selling the language to your existing
development team. It's not a glamorous language that people want on
their CVs. And for some reason quite a lot of people have preconceived
ideas about it - and not many of them are good. "Slow," "ugly GUI,"
"poor tool support," "a bit weird," that sort of thing.
When I got the chance to do a project for the company I was working for
a few years back I convinced management that Tcl was the way to go quite
easily. The 30 or so scripters we had, who were all used to Perl and
Shell, pushed back really hard. I pushed back even harder. One guy dug
his heels in and said it wasn't of any use to his career and so he
wasn't having anything to do with it. He got sacked. It got that nasty.
--
Derek Fountain on the web at http://www.derekfountain.org/
Neil Madden
> Arndt Roger Schneider wrote:
>
>> CAIRO.
>>
>> The Xlib emulation layer should being slashed
>> and Tk must move to Cairo (windows and Aqua, too).
>>
>> pdf is just another backend in cairo --printing done.
>>
>> -roger
>
> Except that Cairo only ships by default on Linux, yes? That wouldn't
> work on Aqua. I thought one of the major reasons for Tk's portability is
> that it hooks into the native windowing system on each platform.
>
The website at http://cairographics.org/ says
"Currently supported output targets include the X Window System, Win32,
image buffers, PostScript, PDF, and SVG file output. Experimental
backends include OpenGL (through glitz), Quartz, and XCB."
So Win32 is supported and Quartz (Aqua) is on the horizon. On the face
of it Tk on top of Cairo would be a very attractive option. License is
GPL or MPL. I don't know if MPL would be compatible with Tcl's BSD-style
license, as I've never read it. Porting Tk to Cairo would be a lot of
work, but would probably go a long way towards the design goals of TkGS.
-- Neil
Bugs
EL
> That wouldn't work on Aqua.
It would in any way work with X11 installed (on OS X).
As Neil mentioned, there is work in progress with cairo on Aqua - and
they certainly use cocoa. People could still use the Cairo/X11 version,
until Cairo/Aqua is finished.
Anyway it would take time to create a Cairo based Tk - And Aqua support
will be better by then.
I think Cairo would be a good approach.
Eckhard
Kevin Walzer
Unless Apple ships Cairo with OS X, this is a non-starter. How many
paying users of a commercial application will want to download and
install Cairo as a dependency?
EL
>> Isn't it the case that in Windows, it's primarily a matter of using the
>> same graphics primitives for the printer that you do for the screen?
> The UNIX/Linux system does not have a 'graphics primitives for the
> printer' API (as far as I know). UNIX systems (and Linix) use X11 for
> graphics and generally X11 does not directly implement printer support.
I think Darren meant that printing support could easily be added to the
Windows version, using windows standard printing interface. That seems
to work like what the X11 layer is doing right now on the screen *on
Windows*.
I have no idea about how printing works, neither on Windows nor on X11.
All I want to do as a user is click an icon and get the print dialog...
And as Tcl programmer I'd like to have something like [.window print
?args?] and it opens that print dialog and puts the thing on paper.
- Eckhard
EL
>> I think Cairo would be a good approach.
>>
>>
>> Eckhard
>
> Unless Apple ships Cairo with OS X, this is a non-starter. How many
> paying users of a commercial application will want to download and
> install Cairo as a dependency?
You could add libcairo.[info sharedlibext] to your application
installer, or extract it from a starkit. Nothing easier than that.
- Eckhard
Robert Heller
Right *now* only the canvas widget has support for 'printing', by having
a the capability of rendering as a postscript file or stream. This is
done by having a postscript drawing function (method) for each graphic
primitive that is supported by the canvas widget. Coupled with exec'ing
or piping with lpstat and lp/lpr, printing a canvas widget is straight
forward under UNIX/Linux or MacOSX. Things kind of fall apart under
MS-Windowss though.
The MS Windows standard printing interface is specific to MS Windows.
UNIX/Linux (X11) does not have a corresponding API, *unless* the Tk
low-level code (which now uses an X11/XLib emulation layer on non-X11
systems (MS Windows & Aqua) is ripped out and replaced with Cario. The
gotcha there is Cario is not presently shipped with either MS Windows or
MacOSX -- this would be a 'step backwards' in a sense for Tcl/Tk, which
presently is cross-platform with no third-party install dependencies.
>
> - Eckhard
Robert Heller
Is is really as simple as that? One single shared library?
BTW: if cario is GPL, this might be problematical for a *commercial*
product. (But obviously not a problem with a GPL open source package.)
Kevin Walzer
>
> BTW: if cario is GPL, this might be problematical for a *commercial*
> product. (But obviously not a problem with a GPL open source package.)
LGPL or Mozilla Public License. Neither of which is directly compatible
with Tcl's BSD-style license, correct?
EL
>> You could add libcairo.[info sharedlibext] to your application
>> installer, or extract it from a starkit. Nothing easier than that.
>
> Is is really as simple as that? One single shared library?
It could be more shared libraries, I don't know. But does it matter
whether you include one shared library or more than one?
> BTW: if cario is GPL, this might be problematical for a *commercial*
> product. (But obviously not a problem with a GPL open source package.)
It's LGPL = *Lesser* GPL. This means it can be included in commercial
applications without problems. All the Gnome and KDE libraries are LGPL,
and are used for commercial apps. Gtk+ is LGPL, and is the basis for SWT
and Eclipse, which in turn are /widely/ used for commercial
applications. The LGPL is kindof like the BSD licence.
Alternatively one could choose the Mozilla license, which I don't know.
But it will probably be less restrictive than GPL...
- Eckhard
Bryan Oakley
> Robert Heller wrote:
>
>>
>> BTW: if cario is GPL, this might be problematical for a *commercial*
>> product. (But obviously not a problem with a GPL open source package.)
>
> LGPL or Mozilla Public License. Neither of which is directly compatible
> with Tcl's BSD-style license, correct?
>
I think a better printing solution to "reimplement Tk on top of Cairo"
is to write code that converts a text widget and/or canvas to PDF. That
seems like the way more useful feature to me. Then I can not only create
something printable, I can create something shareable.
--
Bryan Oakley
http://www.tclscripting.com
Óscar Fuentes
>> BTW: if cario is GPL, this might be problematical for a *commercial*
>> product. (But obviously not a problem with a GPL open source package.)
>
> It's LGPL = *Lesser* GPL. This means it can be included in commercial
> applications without problems.
Not without problems. You must provide source code of the LGPLed code
with your binary distribution and allow the user to replace the library
you provide with his own version:
http://www.gnu.org/licenses/lgpl.html
See paragraph 4: Combined work.
> All the Gnome and KDE libraries are
> LGPL, and are used for commercial apps. Gtk+ is LGPL, and is the basis
> for SWT and Eclipse, which in turn are /widely/ used for commercial
> applications.
The fact that others are using LGPLed code for closed-source projects
does not mean that the license is harmless.
> The LGPL is kindof like the BSD licence.
Not at all.
> Alternatively one could choose the Mozilla license, which I don't
> know. But it will probably be less restrictive than GPL...
It seems so:
http://www.mozilla.org/MPL/MPL-1.1.html
http://en.wikipedia.org/wiki/Mozilla_Public_License
--
Oscar
Óscar Fuentes
> I think a better printing solution to "reimplement Tk on top of Cairo"
> is to write code that converts a text widget and/or canvas to
> PDF. That seems like the way more useful feature to me. Then I can not
> only create something printable, I can create something shareable.
My applications generate PDF as a mean to print, view and share
documents, so I agree with you about the convenience of PDF
generation. However, printing a pdf document on some systems
(e.g. Windows) is far from trivial, even when you install something like
Ghostscript (wich is quite heavyweight).
A Tcl printing solution shouldn't require third-party components that
are impractical to distribute with current Tcl installers (ActiveTcl,
ETCL, etc).
Cairo supports multiple ``devices". Maybe it is worth investigating how
suitable it is for printing on Windows. This way, the same code can
be used to generate PDF or for printing, so the text widget conversion
you propose would be useful for various purposes.
--
Oscar
Bryan Oakley
> Bryan Oakley <oak...@bardo.clearlight.com> writes:
>
>> I think a better printing solution to "reimplement Tk on top of Cairo"
>> is to write code that converts a text widget and/or canvas to
>> PDF. That seems like the way more useful feature to me. Then I can not
>> only create something printable, I can create something shareable.
>
> My applications generate PDF as a mean to print, view and share
> documents, so I agree with you about the convenience of PDF
> generation. However, printing a pdf document on some systems
> (e.g. Windows) is far from trivial, even when you install something like
> Ghostscript (wich is quite heavyweight).
On any modern system you shouldn't have to install anything to print
PDF. What PC in the wild doesn't have a PDF reader (and thus, a way to
print PDF) these days? I know the number is greater than zero, but
surely it's also just a tiny fraction of all desktop machines.
>
> A Tcl printing solution shouldn't require third-party components that
> are impractical to distribute with current Tcl installers (ActiveTcl,
> ETCL, etc).
Agreed. Though I will argue that being able to generate PDF and not
having a way to print it on some under-configured machine is still way
better than the current situation.
I can't help but believe that the effort to write a function to convert
the contents of a text widget to a PDF must be considerably easier (and
more likely to happen) than rewriting all of Tk on top of cairo.
EL
> EL <eckhar...@gmx.de> writes:
>> It's LGPL = *Lesser* GPL. This means it can be included in commercial
>> applications without problems.
>
> Not without problems. You must provide source code of the LGPLed code
> with your binary distribution and allow the user to replace the library
> you provide with his own version:
>
> http://www.gnu.org/licenses/lgpl.html
Ok, but seen from a practical point of view, this is no problem. They
can have the source code of Cairo, I don't care as an app provider (they
can get it anyway from the public CVS). As long as I can keep the code
closed that was written by me, it is fine.
And regarding the libraries: If users want to substitute the libcairo
that comes with my application, it's their own beer (maybe I will need
to tell them in a support call or in the docs).
More of a problem could be distribution with Tcl/Tk itself: Would it be
possible and legal to distribute libcairo as part of Tcl, or would it be
necessary that users download it separately?
- Eckhard
Robert Heller
This will work anywhere GhostScript is installed:
proc CanvasToPDF {canvas PDFfile} {
set output [open "|[auto_execok ps2pdf] - $PDFfile" w]
$canvas postscript -channel $output
close $output
EL
> I can't help but believe that the effort to write a function to convert
> the contents of a text widget to a PDF must be considerably easier (and
> more likely to happen) than rewriting all of Tk on top of cairo.
Certainly, but it would not do much more or better than the current
postscript output. You can also take the postscript output and mangle it
through a ps->pdf converter... Still it does not work for tables,
treeviews, and the like and still it is tedious and complicated.
Tk on top of Cairo would have printing plus PDF, plus much more. It
would mean that you can have *all* of Cairo's functionality, the things
that are already there and the things that come in Cairo in the future.
- Eckhard
Robert Hicks
I think it would be worthwhile to be able to capture text and canvas
items like that. I am not sure if you would modify the text and canvas
widgets or just write something in pure Tcl that could be put in
tcllib.
Robert
Óscar Fuentes
> On any modern system you shouldn't have to install anything to print
> PDF. What PC in the wild doesn't have a PDF reader (and thus, a way to
> print PDF) these days? I know the number is greater than zero, but
> surely it's also just a tiny fraction of all desktop machines.
A pdf viewer is not standard on Windows installations, so you there are
lots of Windows machines that are unable to view/print pdf without
installing some component.
BTW, using the Adobe PDF Reader for printing a document from another
application is far from trivial (if you want to do it in a robust and
elegant way).
[snip]
--
Oscar
Robert Heller
>
> Óscar Fuentes wrote:
> > Bryan Oakley <oak...@bardo.clearlight.com> writes:
> >
> >> I think a better printing solution to "reimplement Tk on top of Cairo"
> >> is to write code that converts a text widget and/or canvas to
> >> PDF. That seems like the way more useful feature to me. Then I can not
> >> only create something printable, I can create something shareable.
> >
> > My applications generate PDF as a mean to print, view and share
> > documents, so I agree with you about the convenience of PDF
> > generation. However, printing a pdf document on some systems
> > (e.g. Windows) is far from trivial, even when you install something like
> > Ghostscript (wich is quite heavyweight).
>
> On any modern system you shouldn't have to install anything to print
> PDF. What PC in the wild doesn't have a PDF reader (and thus, a way to
> print PDF) these days? I know the number is greater than zero, but
> surely it's also just a tiny fraction of all desktop machines.
You would be supprised at how large the number is (really!). Yes, it it
"trivial" to download and install Acrobat Reader, but it *does not*
come bundled with a fresh MS-Windows OEM install -- that is, a
MS-Windows box fresh from the factory won't have a PDF reader. In many
"corporate" (read: insitutional) environments it is *forbidden* for the
office workers to download and install random software on their
machines -- only corporate sanctioned software is allowed. Mostly
because of software license audits and worry over viruses and such. And
many home PCs don't have it installed either -- just because it is
"trivial" to download and install Acrobat Reader, many people don't for
all sorts of 'silly' reasons.
*Every* Linux box comes with *at least* one Postscript/PDF reader
bundled with the base install. MacOSX also comes with Postscript/PDF
support as part of the OS.
>
> >
> > A Tcl printing solution shouldn't require third-party components that
> > are impractical to distribute with current Tcl installers (ActiveTcl,
> > ETCL, etc).
>
> Agreed. Though I will argue that being able to generate PDF and not
> having a way to print it on some under-configured machine is still way
> better than the current situation.
>
> I can't help but believe that the effort to write a function to convert
> the contents of a text widget to a PDF must be considerably easier (and
> more likely to happen) than rewriting all of Tk on top of cairo.
It probably is. It just will leave us in somewhat the same state we are
in now WRT MS-Windows. It really is trivial to transfer the contents of
a text widget to a 'scratch' canvas widget, a page at a time, convert it
to PostScript, and pipe it to lp/lpr under UNIX/Linux or MacOSX, after
having used lpstat to create a print dialog to select from the available
printers.
Bryan Oakley
> Bryan Oakley schrieb:
>
>> I can't help but believe that the effort to write a function to
>> convert the contents of a text widget to a PDF must be considerably
>> easier (and more likely to happen) than rewriting all of Tk on top of
>> cairo.
>
> Certainly, but it would not do much more or better than the current
> postscript output.
I guess we'll have to agree to disagree on that point. I find PDF
infinitely more usable than postscript, and I suspect most of my
non-computer-savvy acquaintances do, too. For them, viewing and printing
PDF is pretty much a no-brainer.
Óscar Fuentes
>> Not without problems. You must provide source code of the LGPLed code
>> with your binary distribution and allow the user to replace the library
>> you provide with his own version:
>>
>> http://www.gnu.org/licenses/lgpl.html
>
> Ok, but seen from a practical point of view, this is no problem. They
> can have the source code of Cairo, I don't care as an app provider
> (they can get it anyway from the public CVS).
This is not enough. *You* must provide a convenient way of getting the
source code of precisally the LGPLed library *you* distribute on binary
form.
[snip]
> More of a problem could be distribution with Tcl/Tk itself: Would it
> be possible and legal to distribute libcairo as part of Tcl, or would
> it be necessary that users download it separately?
IANAL.
The LGPL issue is not to be taken lightly. I'm a Tcl/Tk user because the
GUI library I liked was covered by the LGPL and I considered it a
handicap serious enough to consider other options.
--
Oscar
Bryan Oakley
> Bryan Oakley <oak...@bardo.clearlight.com> writes:
>
>> On any modern system you shouldn't have to install anything to print
>> PDF. What PC in the wild doesn't have a PDF reader (and thus, a way to
>> print PDF) these days? I know the number is greater than zero, but
>> surely it's also just a tiny fraction of all desktop machines.
>
> A pdf viewer is not standard on Windows installations, so you there are
> lots of Windows machines that are unable to view/print pdf without
> installing some component.
I'm aware it's not part of Windows proper (or *nix for that matter), but
I still think the vast majority of desktops have a PDF reader. Too many
companies produce pdf these days to survive without it. Bank statements,
tax forms, product data sheets, etc. I'm not so worried about the
theoretical limitations of pdf as a printing solution as I am the
practicality of it.
> BTW, using the Adobe PDF Reader for printing a document from another
> application is far from trivial (if you want to do it in a robust and
> elegant way).
I don't care about robust and elegant nearly as much as I am in just
making it possible. I personally find it quite acceptable to put in my
documentation "to print, select File->Save as PDF, then open the file
and print it as you would any other pdf document". I would even count
that as a feature.
<shrug>
Óscar Fuentes
>> I think a better printing solution to "reimplement Tk on top of Cairo"
>> is to write code that converts a text widget and/or canvas to PDF. That
>> seems like the way more useful feature to me. Then I can not only create
>> something printable, I can create something shareable.
>
> This will work anywhere GhostScript is installed:
>
> proc CanvasToPDF {canvas PDFfile} {
> set output [open "|[auto_execok ps2pdf] - $PDFfile" w]
> $canvas postscript -channel $output
> close $output
> }
... as long as ps2pdf is in your PATH, and there is no other executables
named ps2pdf {exe|com|bat...} before GhostScript's one in the PATH, and
GhostScript's installation is correct, and the antivirus or software
firewall allows your application to exec ps2pdf ...
--
Oscar
Óscar Fuentes
>> A pdf viewer is not standard on Windows installations, so you there are
>> lots of Windows machines that are unable to view/print pdf without
>> installing some component.
>
> I'm aware it's not part of Windows proper (or *nix for that matter),
> but I still think the vast majority of desktops have a PDF reader.
Applications are deployed on PCs that are not desktops: point of sales,
kiosks, etc. Applications are deployed on desktops used by clueless
users, too. If my installer needs to run another install and make sure
it succeeds (because this is needed by my app) the complexity of my
installer raises quite a bit.
[snip]
>> BTW, using the Adobe PDF Reader for printing a document from another
>> application is far from trivial (if you want to do it in a robust and
>> elegant way).
>
> I don't care about robust and elegant nearly as much as I am in just
> making it possible.
As a professional developer, making it possible is just the very
beginning of my work. Making the app robust and elegant is essential.
> I personally find it quite acceptable to put in my
> documentation "to print, select File->Save as PDF, then open the file
> and print it as you would any other pdf document". I would even count
> that as a feature.
You are free to state and hold your personal opinions, but please read
again the subject of this thread :-) Just imagine yourself saying to the
user: "to print the invoice, press the View button, then wait until a
pfd viewer pops on your screen, then press Control-P to print, select
the name of the impact printer, press Print and close the viewer's
window".
> <shrug>
Indeed! :-)
--
Oscar
Bugs
Lack of printing support has been a big problem for such a long time
that adding the ability to output PDF from the Canvas widget would at
least provide a viable printing option. Also, PDF output from the
canvas widget would "seem" to parallel the reasons to add the postscript
option in the first place, but with a more ubiquitous output format in PDF.
Isn't PDF built on top of PostScript, but with additional
features/functionality? If that is true, what would be the effort to
update the canvas widget to also output PDF? Anyone know who added the
PostScript output feature to the canvas widget in the first place?
Robert Heller
>
> Óscar Fuentes wrote:
> > Bryan Oakley <oak...@bardo.clearlight.com> writes:
> >
> >> On any modern system you shouldn't have to install anything to print
> >> PDF. What PC in the wild doesn't have a PDF reader (and thus, a way to
> >> print PDF) these days? I know the number is greater than zero, but
> >> surely it's also just a tiny fraction of all desktop machines.
> >
> > A pdf viewer is not standard on Windows installations, so you there are
> > lots of Windows machines that are unable to view/print pdf without
> > installing some component.
>
> I'm aware it's not part of Windows proper (or *nix for that matter), but
At this point almost all *nix *desktops* are Linux or MacOSX desktops
(a SparcStation is vastly more costly than your off-the-shelf
WintelBox+Linux installer CD(s)/DVD or even an IntelMac now). All
Linux distros come with GhostScript and one of *several* other PDF
viewers (such as xpdf). MacOSX has PDF 'built in' to the OS. For all
practical purposes, virtually all *nix desktops have a PDF viewer
built-in to the base system install, without needing to download Adobe's
reader.
> I still think the vast majority of desktops have a PDF reader. Too many
> companies produce pdf these days to survive without it. Bank statements,
> tax forms, product data sheets, etc. I'm not so worried about the
> theoretical limitations of pdf as a printing solution as I am the
> practicality of it.
Yes, all this is true, but still many people don't have a PDF viewer on
their PC! Yes, PDF is the proper solution, in theory. I would be very
happy to use it, except I *know* there are going to be some people who
will have problems with it. My Model Railroad System's two major
programs produce PDF output (one directly and one via pdflatex).
>
> > BTW, using the Adobe PDF Reader for printing a document from another
> > application is far from trivial (if you want to do it in a robust and
> > elegant way).
>
> I don't care about robust and elegant nearly as much as I am in just
> making it possible. I personally find it quite acceptable to put in my
> documentation "to print, select File->Save as PDF, then open the file
> and print it as you would any other pdf document". I would even count
> that as a feature.
So would I, but I know some people will have trouble with it. I have a
solution that works cleanly under UNIX/Linux and MacOSX (piping
postscript to lp/lpr, using lpstat to populate a print dialog), but
doesn't under MS-Windows. OTOH, print-to-PDF or Save as PDF, would
probably be 'quite acceptable' to most Linux or MacOSX users and would
probably confuse most MS-Windows users, even those with Adobe's Reader
installed! It seems to be a case of dammed if you do AND dammed if you
don't...
>
> <shrug>
dito...
Robert Heller
Yes, this is a 'quick and dirty' hack, something I wrote off the cuf.
Generally on most Linux machines this will work. There are probably
better solutions though.
Bugs
are "pretty" again, I wonder if more developers might now consider
Tcl/Tk for their GUI development projects ...
Bugs wrote:
> What obstacles are there to using Tcl/Tk for commercial application
> development? Any folks here with experience in this area???
> What things in particular made it a challenge to use Tcl/Tk to develop a
> commercial application?
>
> e.g. Licensing, distribution, lack of printing support, etc.
>
> Thanks!
gavino
> Bugs wrote:
> > What obstacles are there to using Tcl/Tk for commercial application
> > development?
>
>
> > Any folks here with experience in this area???
>
> early 90s.
>
> > What things in particular made it a challenge to use Tcl/Tk to develop a
> > commercial application?
>
> > e.g. Licensing, distribution, lack of printing support, etc.
>
>
> A platform independent printing solution is non-existent. However many
> commercial applications can make use of a platform specific solution.
>
> Many people feel, for some strange reason, to tell clients that their
> product is written in Tcl/Tk. Since it is not one of the current buzz words
> some "management" types have problem with that. My solution has always been
> to say it is our software and none of their business -- politely of course.
> Interesting enough, the only other language that people seem to insist on
> saying their applications are in is Java -- because it is a buzz word and
> they hope that people will buy it for the Java label and ignore the
> shortcomings.
>
> --
> +--------------------------------+---------------------------------------+
> | Gerald W. Lester |
> |"The man who fights for his ideals is the man who is alive." - Cervantes|
> +------------------------------------------------------------------------+
and if java and ATG dynamo are spoken, run...run as fast as you
can....and get the next flight out.....
gavino
> > distribution,
>
> This can be tricky. Source code protection is definitely an issue
> which does not come out of the box in Tcl. But there are solutions for
> all needs, ranging from obfuscation to byte compiling to encryption.
>
> > lack of printing support
>
> There is no cross-platform solution for this (perhaps apart from
> tclbitprint), which may be an obstacle to software trying to be the
> same across platforms. And it is not only the canvas, as Robert
> mentioned, it is also the text widget and perhaps some tables (from
> tktable or tablelist) that would need printing support.
>
> But all in all, there's nearly nothing you cannot do in Tcl for
> commercial applications!
>
> Torsten
what are some e commerce shops using tcl right now? is there anything
like digg.com in tcl? I know aol uses aolserver, but not sure if they
use tcl with it or what...
Robert Heller
>
> Bryan Oakley wrote:
> > Kevin Walzer wrote:
> >> Robert Heller wrote:
> >>
> >>>
> >>> BTW: if cario is GPL, this might be problematical for a *commercial*
> >>> product. (But obviously not a problem with a GPL open source package.)
> >>
> >> LGPL or Mozilla Public License. Neither of which is directly
> >> compatible with Tcl's BSD-style license, correct?
> >>
> >
> > I think a better printing solution to "reimplement Tk on top of Cairo"
> > is to write code that converts a text widget and/or canvas to PDF. That
> > seems like the way more useful feature to me. Then I can not only create
> > something printable, I can create something shareable.
> >
> >
> And more realistic as well.
>
> Lack of printing support has been a big problem for such a long time
> that adding the ability to output PDF from the Canvas widget would at
> least provide a viable printing option. Also, PDF output from the
> canvas widget would "seem" to parallel the reasons to add the postscript
> option in the first place, but with a more ubiquitous output format in PDF.
>
> Isn't PDF built on top of PostScript, but with additional
> features/functionality? If that is true, what would be the effort to
PostScript is a programming language (yes really) with primitives that
draw on the 'paper' and PDF is document format. They are really very
different things. A PostScript file is actually a program.
> update the canvas widget to also output PDF? Anyone know who added the
Probably somewhat non-trivial.
I wrote a *simple* (special purpose, text only) set of 'drivers' for
PostScript and PDF output for one of the programs in my Model Railroad
System. Checkout the differences in line count:
gollum.deepsoft.com% wc -l PDFPrinter* PostScriptPrinter.*
335 PDFPrinter.cc
194 PDFPrinter.h
538 PDFPrinterSupport.cc
1200 PDFPrinterSupport.h
451 PostScriptPrinter.cc
165 PostScriptPrinter.h
2883 total
Both drivers have the same functionallity: print text using three fonts
(roman, italics, bold), three spacings (normal, condensed, double wide),
and not much else (page feeds, line feeds).
> PostScript output feature to the canvas widget in the first place?
>
--
Darren New
> You would be supprised at how large the number is (really!). Yes, it it
> "trivial" to download and install Acrobat Reader, but it *does not*
> come bundled with a fresh MS-Windows OEM install
That would depend on the OEM, really. Does the OEM bundle anything that
needs PDF support?
> *Every* Linux box comes with *at least* one Postscript/PDF reader
> bundled with the base install.
Uhhhh... I'd doubt that. I don't expect Google, for example, installs a
PDF reader on every one of their trillion+ servers. Amazon's ECC doesn't
have a PDF displayer by default. It's all what comes in the distro
you're using.
> It probably is. It just will leave us in somewhat the same state we are
> in now WRT MS-Windows. It really is trivial to transfer the contents of
> a text widget to a 'scratch' canvas widget, a page at a time, convert it
> to PostScript, and pipe it to lp/lpr under UNIX/Linux or MacOSX, after
> having used lpstat to create a print dialog to select from the available
> printers.
Why is it harder to do that from Windows, without going through the
postscript on the way? It's not like it's so difficult to print from
Windows that nobody has figured it out.
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
Darren New
> The UNIX/Linux system does not have a 'graphics primitives for the
> printer' API (as far as I know).
Right. That's why I was surprised that you called the Windows printing
API "rotten". There isn't any UNIX API at all - every program has to
reinvent a "my drawing -> postscript" function, even if the user doesn't
have a postscript printer.
> There are some important differences between printing and displaying,
> not the least of which is things like pagination.
But you have to solve that for postscript too. It's kind of built into
the problem space.
Darren New
> The MS Windows standard printing interface is specific to MS Windows.
As is the drawing interface.
> UNIX/Linux (X11) does not have a corresponding API, *unless* the Tk
> low-level code (which now uses an X11/XLib emulation layer on non-X11
> systems (MS Windows & Aqua) is ripped out and replaced with Cario.
Errrr, no. Why not have the drawing level generate the print-out? I.e.,
put the printing support *under* the X11 emulation, rather than
complaining that Windows printing sucks because X11 doesn't support it?
Darren New
> what are some e commerce shops using tcl right now?
I'm not sure about "right now", but the first ever online shopping mall
was implemented entirely in Tcl (back in the v7.4 days), including the
e-commerce part of it and the "upload your stuff and we'll sell it for
you" part.
Indeed, all my e-commerce stuff is written in Tcl since then.
Bugs
[snip]
> I wrote a *simple* (special purpose, text only) set of 'drivers' for
> PostScript and PDF output for one of the programs in my Model Railroad
> System. Checkout the differences in line count:
>
> gollum.deepsoft.com% wc -l PDFPrinter* PostScriptPrinter.*
> 335 PDFPrinter.cc
> 194 PDFPrinter.h
> 538 PDFPrinterSupport.cc
> 1200 PDFPrinterSupport.h
> 451 PostScriptPrinter.cc
> 165 PostScriptPrinter.h
> 2883 total
>
Donal K. Fellows
> Tk on top of Cairo would have printing plus PDF, plus much more. It
> would mean that you can have *all* of Cairo's functionality, the things
> that are already there and the things that come in Cairo in the future.
There are two, maybe three, sorts of printing. The first is the "I want
to produce nicely paginated documents" problem. The second is "I want to
reproduce what's on the screen" (and that splits into "exactly what I
see" and "the entities that are conceptually there"; it is the latter
that the canvas does when generating postscript). I'm not convinced that
a solution for one of these is a solution for the others, and nor am I
sure I understand what Cairo would gain us with respect to these goals.
But that aside, anyone wanting to work on better printing or a new
rendering engine for Tk will get my (moral) support. They're two of the
big-ticket items on the Tk9 wish list (though printing doesn't *have* to
wait that long, and a new rendering engine will pretty much define when
we change major version numbers!)
Donal.
Donal K. Fellows
> Except that Cairo only ships by default on Linux, yes?
That'd be a problem on other Unix platforms, which we still support.
Yes, really.
Donal.
Mark Roseman
> OTOH, print-to-PDF or Save as PDF, would
> probably be 'quite acceptable' to most Linux or MacOSX users
I can't say for Linux users, but to suggest that as a proper or
acceptable solution for most OS X users is completely wrong. It may
well be a grudgingly tolerable solution, but from a user experience
point of view, that's just not how printing is done.
Not to say it wouldn't be a huge improvement over what's there now of
course. :-)
Mark
p.s. realistically, if you were to do such a thing, it would be done as
a "preview" operation which would write the PDF and launch Preview.app;
so in other words you might just get away with it if you don't actually
call it "printing"...
Larry W. Virden
> EL wrote:
> > Kevin Walzer schrieb:
>
> >> That wouldn't work on Aqua.
>
> > It would in any way work with X11 installed (on OS X).
> > As Neil mentioned, there is work in progress with cairo on Aqua - and
> > they certainly use cocoa. People could still use the Cairo/X11 version,
> > until Cairo/Aqua is finished.
> > Anyway it would take time to create a Cairo based Tk - And Aqua support
> > will be better by then.
>
> > I think Cairo would be a good approach.
>
> > Eckhard
>
> Unless Apple ships Cairo with OS X, this is a non-starter. How many
> paying users of a commercial application will want to download and
> install Cairo as a dependency?
>
Won't that be true, as well, for HP, Solaris, Linux, and the rest of
Unix, Windows, etc. users? If it doesn't come pre-installed, will
people want to go through the process of installing a major
infrastructure component?
Robert Heller
>
> Robert Heller wrote:
> > You would be supprised at how large the number is (really!). Yes, it it
> > "trivial" to download and install Acrobat Reader, but it *does not*
> > come bundled with a fresh MS-Windows OEM install
>
> That would depend on the OEM, really. Does the OEM bundle anything that
> needs PDF support?
Generally not. OEMs bundle little these days because of anti-trust
issues (mostly what was bundled was M$'s software: Office, etc.).
>
> > *Every* Linux box comes with *at least* one Postscript/PDF reader
> > bundled with the base install.
>
> Uhhhh... I'd doubt that. I don't expect Google, for example, installs a
> PDF reader on every one of their trillion+ servers. Amazon's ECC doesn't
> have a PDF displayer by default. It's all what comes in the distro
> you're using.
I'm refering to *desktops*, not servers! And the distros thay Google or
Amazon is using (most likely RHEL) come is ghostscript.
>
> > It probably is. It just will leave us in somewhat the same state we are
> > in now WRT MS-Windows. It really is trivial to transfer the contents of
> > a text widget to a 'scratch' canvas widget, a page at a time, convert it
> > to PostScript, and pipe it to lp/lpr under UNIX/Linux or MacOSX, after
> > having used lpstat to create a print dialog to select from the available
> > printers.
>
> Why is it harder to do that from Windows, without going through the
> postscript on the way? It's not like it's so difficult to print from
> Windows that nobody has figured it out.
The MS-Windows API is *missing* the external CLI programs: a lpstat like
program and a lp/lpr like program, with a postscript-to-printer filter.
The MS-Windows API depends on a MS-Windows specific graphics API.
For UNIX and MacOSX, all a program needs to do is generate postscript
and pipe it to lp or lpr. One can get a list of available printers
with lpstat. To print from MS-Windows, it is necessary to write
additional functionallity into the *core*, in the form of an additional
'slot' in all of the canvas item code -- a MS-Windows specific
"drawing" function as a replacement (or in addition to) for the current
postscript command. UNIX does not have such a graphical API. I guess
we need to create an abstraction layer/library that replaces the
existing postscript driver code -- the MS-Windows library would talk to
the MS-Windows specific (printer) graphics API and the UNIX library
would generate postscript. Then there are issues relating to the how
the MS-Windows specific (printer) graphics is a completely different
sort of thing than the postscript generator is. Going to Cairo *might*
be a solution, except that Cairo is a third-party, separately
installed, package, which opens a whole additional can of worms.
Robert Heller
>
> Robert Heller wrote:
> > The UNIX/Linux system does not have a 'graphics primitives for the
> > printer' API (as far as I know).
>
> Right. That's why I was surprised that you called the Windows printing
> API "rotten". There isn't any UNIX API at all - every program has to
> reinvent a "my drawing -> postscript" function, even if the user doesn't
> have a postscript printer.
All printers under Linux *appear* as postscript printer, thanks to the
ghostscript filters used by lpd or CUPS, so if you have a printer on
your Linux or UNIX box it is in effect a postscript printer.
>
> > There are some important differences between printing and displaying,
> > not the least of which is things like pagination.
>
> But you have to solve that for postscript too. It's kind of built into
> the problem space.
>
--
Robert Heller
>
> EL wrote:
> > Tk on top of Cairo would have printing plus PDF, plus much more. It
> > would mean that you can have *all* of Cairo's functionality, the things
> > that are already there and the things that come in Cairo in the future.
>
> There are two, maybe three, sorts of printing. The first is the "I want
> to produce nicely paginated documents" problem. The second is "I want to
> reproduce what's on the screen" (and that splits into "exactly what I
> see" and "the entities that are conceptually there"; it is the latter
> that the canvas does when generating postscript). I'm not convinced that
> a solution for one of these is a solution for the others, and nor am I
> sure I understand what Cairo would gain us with respect to these goals.
I've used the 'encapulated postscript' feature of the existing canvas ->
postscript code to 'to produce nicely paginated documents'.
>
> But that aside, anyone wanting to work on better printing or a new
> rendering engine for Tk will get my (moral) support. They're two of the
> big-ticket items on the Tk9 wish list (though printing doesn't *have* to
> wait that long, and a new rendering engine will pretty much define when
> we change major version numbers!)
>
> Donal.
>
--
frederi...@free.fr
> I think a better printing solution to "reimplement Tk on top of Cairo"
> is to write code that converts a text widget and/or canvas to PDF. That
> seems like the way more useful feature to me. Then I can not only create
> something printable, I can create something shareable.
Something along the lines of TkPath and TclBitPrint?
http://wiki.tcl.tk/14545
http://wiki.tcl.tk/12943
http://sourceforge.net/projects/tclbitprint
Robert Heller
Yep. Although the package management for Linux and some others might
'take care' of this transparently (eg an 'apt-get install tk' or 'yum
install tk' will pull the package for Cairo and install it). Of course
this does fall flat for a 'self contained' startkit or freewrapped
program.
frederi...@free.fr
> So Win32 is supported and Quartz (Aqua) is on the horizon. On the face
> of it Tk on top of Cairo would be a very attractive option. License is
> GPL or MPL. I don't know if MPL would be compatible with Tcl's BSD-style
> license, as I've never read it. Porting Tk to Cairo would be a lot of
> work, but would probably go a long way towards the design goals of TkGS.
Yes, Cairo reached the goals that TkGS pursued, that's why the latter
is no longer relevant (hopefully because I had to give up my work on
this project due to critical lack of time). The only open issue is
licensing. Cairo currently provides two licenses: LGPL and MPL. To
what extent the MPL might be compatible with Tcl, I have no idea.
frederi...@free.fr
> To what extent the MPL might be compatible with Tcl, I have no idea.
[a few minutes later...]
Disclaimer: IANAL.
According to the MPL FAQ (http://www.mozilla.org/MPL/mpl-faq.html) it
seems that a MPL-licensed Cairo would be compatible with Tk, either in
binary form, or mixed with BSD-licensed code:
---------------------
Q: I want to distribute complete and unchanged binary packages
provided by mozilla.org. What do I have to do?
A: Nothing. :-)
[...]
You do not require a Mozilla Foundation trademark license.
Q: May I combine MPLed code and BSD-licensed code in the same binary?
A: Yes. mozilla.org does this - for example libjpeg, which decodes
JPEG images, is under a BSD license
---------------------
It seems that licensing issues only arise with GPL.
Robert Heller
This code seems to be broken -- the included binaries expect
libcairo.so.1, which I can't find -- I found libcairo.so.2. The does
not build with libcairo V2 either. It looks like this code is outdated
and does not seem to be kept up.
Eckhard Lehmann
<donal.k.fell...@manchester.ac.uk> wrote:
> EL wrote:
> There are two, maybe three, sorts of printing. The first is the "I want
> to produce nicely paginated documents" problem. The second is "I want to
> reproduce what's on the screen" (and that splits into "exactly what I
> see" and "the entities that are conceptually there"; it is the latter
> that the canvas does when generating postscript).
The first sort is what is desired, I'd say.
The second sort is implemented via screen shots that you can take from
every application (it's what the users of a former project of mine did
for printing as a workaround).
> I'm not convinced that
> a solution for one of these is a solution for the others, and nor am I
> sure I understand what Cairo would gain us with respect to these goals.
I have no idea either, but I know that cairo is used as a backend in
many applications, e.g. also in OOo. I don't know more details about
these, though - just heard that it was slow some time ago.
Maybe cairo is not the best solution, technically or with regards to
the license... but it could be one. (as a side effect it could make
Tcl more popular, since many people talk about cairo ;)).
Nevertheless I agree that there could be better options. Anyway, I am
not the one to decide that - developing this print support is
definitely "out of scope" for me.
- Eckhard
frederi...@free.fr
> At Thu, 24 Jan 2008 05:06:52 -0800 (PST) fredericbon...@free.fr wrote:
>
>
>
> > On Jan 23, 11:00 pm, Bryan Oakley <oak...@bardo.clearlight.com> wrote:
> > > I think a better printing solution to "reimplement Tk on top of Cairo"
> > > is to write code that converts a text widget and/or canvas to PDF. That
> > > seems like the way more useful feature to me. Then I can not only create
> > > something printable, I can create something shareable.
>
> > Something along the lines of TkPath and TclBitPrint?
>
> >http://wiki.tcl.tk/14545
> >http://wiki.tcl.tk/12943
> >http://sourceforge.net/projects/tclbitprint
>
> This code seems to be broken -- the included binaries expect
> libcairo.so.1, which I can't find -- I found libcairo.so.2. The does
> not build with libcairo V2 either. It looks like this code is outdated
> and does not seem to be kept up.
The wiki page says:
"In January, 2008, developer announced 0.2.8, which is a Tk 8.5 only
release (no backward compatibility)."
You can find the announcement there: http://groups.google.com/group/comp.lang.tcl/msg/6dfb34b4113b3db4
Else, sk1 is a neat vector graphics application that uses Cairo and
Ttk/Tile (unfortunately it's written in Python).
Robert Hicks
<snip>
> I don't care about robust and elegant nearly as much as I am in just
> making it possible. I personally find it quite acceptable to put in my
> documentation "to print, select File->Save as PDF, then open the file
> and print it as you would any other pdf document". I would even count
> that as a feature.
>
I agree totally with that! I would be cool, IMO, if you could somehow
retool the canvas and text widget to spit out a pdf. How is that
currently accomplished?
Robert
schlenk
Not too hard, just a bit of work. Just hack at the C code in Tk's
canvas code and replace the literal postscript stuff with a good call
to Tcl_Eval and build upon pdf4tcl to get things done.
(or for a simpler thing use a snit widgetadaptor and wrap a pdf layer
around the canvas)
Michael
schlenk
Bryan Oakley
It looks like trampoline hasn't been touched in over three years. It but
it appears to have died on the vine.
--
Bryan Oakley
http://www.tclscripting.com
Darren New
> The MS-Windows API is *missing* the external CLI programs: a lpstat like
> program and a lp/lpr like program, with a postscript-to-printer filter.
Why do you need that? You open the printer queue as a file and write to
it. You don't need an API - you use the copy command.
It's missing a postscript-to-printer filter, yes, but that's only a
problem if you insist that generating postscript is the best and only
way of printing something.
> The MS-Windows API depends on a MS-Windows specific graphics API.
Yes, but it's essentially the *same* API that writes to the screen. You
don't need to generate postscript - you simply print directly to the
printer.
> For UNIX and MacOSX, all a program needs to do is generate postscript
> and pipe it to lp or lpr. One can get a list of available printers
> with lpstat. To print from MS-Windows, it is necessary to write
> additional functionallity into the *core*, in the form of an additional
> 'slot' in all of the canvas item code -- a MS-Windows specific
> "drawing" function as a replacement (or in addition to) for the current
> postscript command.
Right. In other words, Windows is harder because it's not already
implemented. Sure. Complaining it's a problem with Windows printing
support is like complaining that X-Windows isn't compatible with win32
and therefore sucks.
> UNIX does not have such a graphical API.
It does - X-Windows. It's just that you have to use a *different* API
for printing than you do for the rest of your graphics work.
> Then there are issues relating to the how
> the MS-Windows specific (printer) graphics is a completely different
> sort of thing than the postscript generator is.
Yeah, but it's the *same* thing as what's already in the canvas to draw
on the screen. Windows treats the printer as (essentially) a different
screen (modulo selecting preferences, pagination, etc). If you can draw
on the screen, you have what you need to draw on the printer.
Starting out by saying "we already have support for drawing on UNIX,
printing from UNIX, and drawing on Windows, so we need to make printing
on Windows look like printing on UNIX" doesn't seem like the optimal
approach to solving the problem.
Darren New
> At Wed, 23 Jan 2008 19:21:46 -0800 Darren New <dn...@san.rr.com> wrote:
>
>> Robert Heller wrote:
>>> The UNIX/Linux system does not have a 'graphics primitives for the
>>> printer' API (as far as I know).
>> Right. That's why I was surprised that you called the Windows printing
>> API "rotten". There isn't any UNIX API at all - every program has to
>> reinvent a "my drawing -> postscript" function, even if the user doesn't
>> have a postscript printer.
>
> All printers under Linux *appear* as postscript printer, thanks to the
> ghostscript filters used by lpd or CUPS, so if you have a printer on
> your Linux or UNIX box it is in effect a postscript printer.
And all printers under Windows appear as the same kind of graphics
device you're already using to draw on the screen. That means you only
have to write your drawing code once, instead of under UNIX writing it
once for the screen and once for the printer.
The general way it works is a Windows app says "I want to print
something." The user gets the dialog box, and then the OS calls back to
say "here's a window into which you should draw page 1", then "here's a
window into which you should draw page 2", and so on. You use the exact
same drawing mechanisms, fonts, color operations, clipping, etc as you
use when Windows says "the user just uncovered your window, so redraw
the contents."
Starting with the presumtion that printing *has* to go via postscript,
then trying to solve it for Windows, is just making it more difficult.
schlenk
Bryan Oakley wrote:
> schlenk wrote:
> > Should mention Trampoline...
> > http://trampoline.sourceforge.net/
> >
> > Michael
>
> It looks like trampoline hasn't been touched in over three years. It but
> it appears to have died on the vine.
Yes, looks like it. But at least one would not have to start from zero
to implement PDF for the canvas if one picked up the work. No idea how
things like pdf4tcl and trampoline might work together.
Michael
Arndt Roger Schneider
To replace the Xlib layer with a cairo layer is
perhaphs a matter of 2 to 3 years.
... In the meantime work will continue on cairo
--i think substantial toward Xrender (X11).
Using cairo for Tk isn't about printing.
A printing solution is just a side-effect.
Porting Tk to cairo will require to fork Tk.
Work on 8.5 should continue during the port.
That is: there might be two Tk 9.0 versions: One Xlib
based and another cairo.
-roger
Robert Heller
>
> Robert Heller wrote:
> > The MS-Windows API is *missing* the external CLI programs: a lpstat like
> > program and a lp/lpr like program, with a postscript-to-printer filter.
>
> Why do you need that? You open the printer queue as a file and write to
> it. You don't need an API - you use the copy command.
How to get a list of printer queues under MS-Windows? Yes, COPY under
MS-Windows will behave like lpr under UNIX.
>
> It's missing a postscript-to-printer filter, yes, but that's only a
> problem if you insist that generating postscript is the best and only
> way of printing something.
>
> > The MS-Windows API depends on a MS-Windows specific graphics API.
>
> Yes, but it's essentially the *same* API that writes to the screen. You
> don't need to generate postscript - you simply print directly to the
> printer.
Yes, but that API is missing from Tk. And is inconsistent with the way
the (existing) canvas postscript.
>
> > For UNIX and MacOSX, all a program needs to do is generate postscript
> > and pipe it to lp or lpr. One can get a list of available printers
> > with lpstat. To print from MS-Windows, it is necessary to write
> > additional functionallity into the *core*, in the form of an additional
> > 'slot' in all of the canvas item code -- a MS-Windows specific
> > "drawing" function as a replacement (or in addition to) for the current
> > postscript command.
>
> Right. In other words, Windows is harder because it's not already
> implemented. Sure. Complaining it's a problem with Windows printing
> support is like complaining that X-Windows isn't compatible with win32
> and therefore sucks.
>
> > UNIX does not have such a graphical API.
>
> It does - X-Windows. It's just that you have to use a *different* API
> for printing than you do for the rest of your graphics work.
Yes. That is the problem. The UNIX 'printer graphics' API (such as it
is) is nothing like the MS-Windows 'printer graphics' API.
>
> > Then there are issues relating to the how
> > the MS-Windows specific (printer) graphics is a completely different
> > sort of thing than the postscript generator is.
>
> Yeah, but it's the *same* thing as what's already in the canvas to draw
> on the screen. Windows treats the printer as (essentially) a different
> screen (modulo selecting preferences, pagination, etc). If you can draw
> on the screen, you have what you need to draw on the printer.
So I guess we need to somehow create a kind of 'window' (a printer
window) to connect a canvas to and then copy the screen canvas to the
printer canvas?
>
> Starting out by saying "we already have support for drawing on UNIX,
> printing from UNIX, and drawing on Windows, so we need to make printing
> on Windows look like printing on UNIX" doesn't seem like the optimal
> approach to solving the problem.
Right. We need two solutions that are not logicaly interchangable and
don't have a common interface layer.
Robert Heller
Yes. Then when the MS-Windows 'way' of printing is implemented, we end
up in a completely different boat: no way to print under UNIX, *unless*
we re-invent the MS-Windows 'way' of printing under UNIX (and probably
end up generating a PostScript or PDF file). Either way, a non-trivial
solution...
Arndt Roger Schneider
[snip]
> So I guess we need to somehow create a kind of 'window' (a printer
> window) to connect a canvas to and then copy the screen canvas to the
> printer canvas?
>
[snip]
In this make sure to use StretchDIBBitBli(b/p) and not
StretchBitBli(b/p) ...
otherwise your entire memory will be to small for the generated
printer image.
-roger
EL
> Yes. Then when the MS-Windows 'way' of printing is implemented, we end
> up in a completely different boat: no way to print under UNIX, *unless*
> we re-invent the MS-Windows 'way' of printing under UNIX (and probably
> end up generating a PostScript or PDF file). Either way, a non-trivial
> solution...
Sorry to say that but your postings in this thread sound a bit narrow
minded.
Please, make yourself aware that there are other platforms than Linux or
Unix and that they may handle things *differently*.
Nobody says that all the postscript code - which kindof works on unix -
should be thrown away in favour of a "Windows" way to handle printing.
We talk about *adding* a windows way for printing, *on Windows*. That's all.
- Eckhard
EL
> If it doesn't come pre-installed, will
> people want to go through the process of installing a major
> infrastructure component?
I am sure most people wouldn't mind to do that. Many will eventually
have it installed anyway, since other applications (like OOo) depend on it.
- Eckhard
Bugs
> I don't care about robust and elegant nearly as much as I am in just
> making it possible. I personally find it quite acceptable to put in my
> documentation "to print, select File->Save as PDF, then open the file
> and print it as you would any other pdf document". I would even count
> that as a feature.
I know a lot of you aren't hot on using a 3rd party apps to do printing
and the concept using a web browser to do the printing duties for you
isn't new but doesn't it offer a decent interim solution, at least for
printing tabular-report type data? One thing we can reasonably count on
is that most modern desktops will have a web browser available.
Perhaps the high-level process might be as follows:
- Generate HTML using the tcllib HTML package (or whatever means you wish).
- After the page is rendered by the browser, immediately execute
Javascript like the following:
function printthispage() {
if (window.print != null) {
window.print();
} else {
alert("To print, please select File and then Print from your browser's
menu.");
}
}
This will immediately bring up the browser's printer selection box.
I've tested this javascript function successfully with Firefox and
Internet Explorer on Windows and Safari on Mac OS X. Linux anyone?
- Alternatively, the browser could act as a poor-man's "print preview",
then instead of executing the javascript immediately you could just have
the print javascript execute if they click a "Click here where ready to
print" link in the HTML.
Just a thought!
Bugs
> I know a lot of you aren't hot on using a 3rd party apps to do printing
> and the concept using a web browser to do the printing duties for you
> isn't new but doesn't it offer a decent interim solution, at least for
> printing tabular-report type data? One thing we can reasonably count on
> is that most modern desktops will have a web browser available.
>
> Perhaps the high-level process might be as follows:
> - Generate HTML using the tcllib HTML package (or whatever means you wish).
> - After the page is rendered by the browser, immediately execute
> Javascript like the following:
>
> function printthispage() {
> if (window.print != null) {
> window.print();
> } else {
> alert("To print, please select File and then Print from your browser's
> menu.");
> }
> }
>
> This will immediately bring up the browser's printer selection box.
> I've tested this javascript function successfully with Firefox and
> Internet Explorer on Windows and Safari on Mac OS X. Linux anyone?
>
> - Alternatively, the browser could act as a poor-man's "print preview",
> then instead of executing the javascript immediately you could just have
> the print javascript execute if they click a "Click here where ready to
> print" link in the HTML.
>
> Just a thought!
>
Oops, I left out the 2nd step, which should be:
- Send the generated .html file to a browser. On windows, you can just
pass the file name to the shell and using the file extension
association, Windows will automatically open the file using your default
browser. Not sure if it would be that easy with OSX or Linux?
Kevin Walzer
> Now that we have Tcl/Tk 8.5 with which to create GUI applications that
> are "pretty" again, I wonder if more developers might now consider
> Tcl/Tk for their GUI development projects ...
>
Well, I just released updates to all three of my commercial applications
today (two use Tcl/Tk + Tile, one uses Python/Tk + Tile), so I'm
certainly doing this!
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Larry W. Virden
It has been my experience that people typically do not wish to install
a tcl extension. I am skeptical that convincing them to install a new
window rendering framework would be simple.
Of course, making such a transition as becoming dependant on Cairo
would have one effect - everyone unable or unwilling to install it
would be "free" to move along to another graphical extension.
Perhaps an alternative way to go would be to create a new graphical
interface dependant on cairo, so that the paths could fork and people
without interest or ability to move in that direction had the ability
to continue obtaining the support they need.
R. Sindermann
> schlenk wrote:
> > Should mention Trampoline...
>> http://trampoline.sourceforge.net/
>>
>> Michael
>
> It looks like trampoline hasn't been touched in over three years. It but
> it appears to have died on the vine.
>
(no work before only 'package require trampoline'
::pdf::generate $canvas $filename
as for postscript-files:
$canvas postscript -file $filename.
or for emf-files (Windows):
MetaFile $canvas -file $filename -format enhanced
from Tkprint (Ian Findleton) for Windows
or (not so easy) for emf-files (Windows):
after some GDI-,printerselection-, printerdialog-, page_setup-commands:
set hDCname [ wmf open -file ]
set hDC [hdc addr $hDCname]
foreach id [$canvas find all] {
set type [$canvas type $id]
printer::print_canvas.[$canvas type $id] $hDC $canvas $id
}
set wmfdc [ wmf close $hDCname ]
wmf copy $wmfdc -file $filename
wmf delete $wmfdc
with the wmfm, hdc, gdi, printer stuff of Michal Schwartz.
But this goes to the windows-printer!
Regards
Rainer Sindermann
Gerald W. Lester
> Óscar Fuentes wrote:
>> Bryan Oakley <oak...@bardo.clearlight.com> writes:
>>
>>> I think a better printing solution to "reimplement Tk on top of Cairo"
>>> is to write code that converts a text widget and/or canvas to
>>> PDF. That seems like the way more useful feature to me. Then I can not
>>> only create something printable, I can create something shareable.
>>
>> documents, so I agree with you about the convenience of PDF
>> generation. However, printing a pdf document on some systems
>> (e.g. Windows) is far from trivial, even when you install something like
>> Ghostscript (wich is quite heavyweight).
>
> On any modern system you shouldn't have to install anything to print
> PDF. What PC in the wild doesn't have a PDF reader (and thus, a way to
> print PDF) these days? I know the number is greater than zero, but
> surely it's also just a tiny fraction of all desktop machines.
> ...
But Acrobat's PDF reader will not print when the print is generated from a
service and no one is logged in.
Got that tee-shirt.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Robert Hicks
"It is also hoped that at some future date Trampoline! would become
part of tklib and TclPDF would become part of tcllib"
That is from the page. It is probably beyond my skills but maybe it
can be looked at, cleaned up and added to tklib and tcllib as desired
by the original author.
Robert
Bruce Stephens
> On Jan 23, 3:02 pm, Kevin Walzer <k...@codebykevin.com> wrote:
[...]
>> Unless Apple ships Cairo with OS X, this is a non-starter. How many
>> paying users of a commercial application will want to download and
>> install Cairo as a dependency?
>
> Won't that be true, as well, for HP, Solaris, Linux, and the rest of
> Unix, Windows, etc. users? If it doesn't come pre-installed, will
> people want to go through the process of installing a major
> infrastructure component?
Is this really a big deal? For a commercial application, don't people
routinely bundle lots of stuff that might not be on the target
machines?
I know at work we do, since we test (and support) our applications
only with specific versions of tcl/tk/tix and a variety of other
components.
(We don't do this with (IIRC) PostgreSQL, but I don't recall the
reasons for that. We also don't do it with JVM, since (IIRC)
licensing makes that impractical. So customers may need to get hold
of a few things (depending on exactly what they want to do), but we
bundle quite a bit of extra code.)
Adding cairo wouldn't be an issue from that perspective. MPL would be
fine. LGPL would be slightly irritating, but also not a showstopper,
I think.
Robert Heller
>
> "Larry W. Virden" <lvi...@gmail.com> writes:
>
> > On Jan 23, 3:02 pm, Kevin Walzer <k...@codebykevin.com> wrote:
>
> [...]
>
> >> Unless Apple ships Cairo with OS X, this is a non-starter. How many
> >> paying users of a commercial application will want to download and
> >> install Cairo as a dependency?
> >
> > Won't that be true, as well, for HP, Solaris, Linux, and the rest of
> > Unix, Windows, etc. users? If it doesn't come pre-installed, will
> > people want to go through the process of installing a major
> > infrastructure component?
>
> Is this really a big deal? For a commercial application, don't people
> routinely bundle lots of stuff that might not be on the target
> machines?
Depends on the target customer base. One thing about Tcl/Tk is things
like freewrap and startkits, which allow bunding a Tcl/Tk application
into a single executable, which can be dropped *anywhere* (even
executed directly off a CD or USB stick) -- no need to install it or
anything else. Cairo as bundled third-party package would be a show
stopper in this case.
>
> I know at work we do, since we test (and support) our applications
> only with specific versions of tcl/tk/tix and a variety of other
> components.
>
> (We don't do this with (IIRC) PostgreSQL, but I don't recall the
> reasons for that. We also don't do it with JVM, since (IIRC)
> licensing makes that impractical. So customers may need to get hold
> of a few things (depending on exactly what they want to do), but we
> bundle quite a bit of extra code.)
>
> Adding cairo wouldn't be an issue from that perspective. MPL would be
> fine. LGPL would be slightly irritating, but also not a showstopper,
> I think.
>
--
Bruce Stephens
[...]
> Depends on the target customer base. One thing about Tcl/Tk is
> things like freewrap and startkits, which allow bunding a Tcl/Tk
> application into a single executable, which can be dropped
> *anywhere* (even executed directly off a CD or USB stick) -- no need
> to install it or anything else. Cairo as bundled third-party
> package would be a show stopper in this case.
If Tk were altered to depend on cairo, presumably starkits and things
would need to adapt (presumably statically linking against the cairo
libs or something).
[...]
Robert Hicks
On OSX you can do: open /Applications/Safari.app index.html
Robert Heller
This *could* get 'sticky' depending on which license (LGPL or MPL) one
used...
>
> [...]
Darren New
> How to get a list of printer queues under MS-Windows?
No idea, offhand. There's obviously an API for it, just like under UNIX.
Of course, a 15-second search on MSDN finds the 3-line answer:
http://msdn2.microsoft.com/en-us/library/aa970783.aspx
(Actually, that's the .NET version. But the regular stuff isn't notably
more difficult at that level.)
Why do you need such a thing, tho?
>> It's missing a postscript-to-printer filter, yes, but that's only a
>> problem if you insist that generating postscript is the best and only
>> way of printing something.
>>
>>> The MS-Windows API depends on a MS-Windows specific graphics API.
>> Yes, but it's essentially the *same* API that writes to the screen. You
>> don't need to generate postscript - you simply print directly to the
>> printer.
>
> Yes, but that API is missing from Tk.
Not exactly. If Tk is drawing to a window in Windows, it can draw to the
printer. It just needs to basically draw to a *different* window. (That
Tk is layered improperly doesn't mean "Windows is rotten". :-)
>>> UNIX does not have such a graphical API.
>> It does - X-Windows. It's just that you have to use a *different* API
>> for printing than you do for the rest of your graphics work.
>
> Yes. That is the problem. The UNIX 'printer graphics' API (such as it
> is) is nothing like the MS-Windows 'printer graphics' API.
The UNIX printer graphics API is nothing like the UNIX screen graphics
API either. I'm not sure where the problem is coming from. There's
already custom code for drawing on X11, drawing on postscript printers,
and drawing on Windows windows.
> So I guess we need to somehow create a kind of 'window' (a printer
> window) to connect a canvas to and then copy the screen canvas to the
> printer canvas?
Yes, exactly. The printer window (called a GDI - Graphic Device
Interface, IIRC) is handed to you once for each page, once you start the
process of "the user wants to print something". Basically, all the
drawing statements like "stroke a pen" and "set a color" and "fill a
rectangle" take the graphics context (printer, window, etc) you want to
draw on as one of the arguments. Replace that graphics context in the
canvas item, refresh the "display", and say "here you are, Windows,
print that out."
Search MSDN.microsoft.com for appropriate terms. Documentation is
usually pretty good, except they prune off older stuff when newer stuff
comes out, which is annoying unless you've actually given them the money
for the development kits.
>> Starting out by saying "we already have support for drawing on UNIX,
>> printing from UNIX, and drawing on Windows, so we need to make printing
>> on Windows look like printing on UNIX" doesn't seem like the optimal
>> approach to solving the problem.
>
> Right. We need two solutions that are not logicaly interchangable and
> don't have a common interface layer.
Well, three. UNIX screen, UNIX printer, Windows graphics. :-)
Darren New
> How to get a list of printer queues under MS-Windows? Yes, COPY under
> MS-Windows will behave like lpr under UNIX.
Well, actually, here's the links (took 90 seconds) for raw C access to
queues and print jobs and such, including the CLI program to do it:
http://support.microsoft.com/kb/196805
http://support.microsoft.com/kb/158828/EN-US/
http://support.microsoft.com/kb/160129/EN-US/
Darren New
> Yes. Then when the MS-Windows 'way' of printing is implemented, we end
> up in a completely different boat: no way to print under UNIX,
We already have a way to print under UNIX, don't we? Why would adding
the code to print under Windows break that? Heck, the code to print
under Windows probably wouldn't even be linked into the executable for
Unix versions of Tk.
bria...@easystreet.net
> Thanks for all the terrific feedback everyone.
>
> Bugs wrote:
> > What obstacles are there to using Tcl/Tk for commercial application
> > development? Any folks here with experience in this area???
> > What things in particular made it a challenge to use Tcl/Tk to develop a
> > commercial application?
>
> > e.g. Licensing, distribution, lack of printing support, etc.
>
> > Thanks!
I surprised that no one mentioned testing. For large commercial
applications, it's absolutely necessary to be able to build and test
the application before shipping it. Commercial viability requires
begin able to repeat this process in a predictable manner while
advancing the capabilities of the product. Tcl has a fundamental
problem in that there are a large class of problems that are
undetectable unless the code is executed and for large applications it
is not feasible to exercise every combination. This is a problem for
all programming languages, but with other languages there are other
ways to test the code. Starting with things like -Wall, developers
and quality assurance engineers can identify potential problems before
any code is executed. Products like Coverity and Purify can dig
deeper into the source code and identify problems that aren't apparent
on the surface.
This doesn't mean Tcl can't be used for commercial applications, it
just means that special care must be taken during the development
process. Many of the successful deployments of Tcl applications are
clearly written and maintained by some of the worlds most talented
programmers. Large applications developed in large shops cannot
always afford or even find the necessary talent for this sort of
endeavor, that's why there are software tools for testing the code and
languages created that are testable.
Tcl's strength is in rapid development, often used for prototyping for
this reason. If it was possible to apply just a little bit of
correctness proofs to Tcl, I'm sure it would turn into a killer
programming language. Printing is solvable, this, I fear, is not.
Please, someone prove me wrong.
-Brian
(developer using tcl in a commercial product)
Joe English
>
> More of a problem could be distribution with Tcl/Tk itself: Would it be
> possible and legal to distribute libcairo as part of Tcl, or would it be
> necessary that users download it separately?
It would be possible and legal to do so,
but I can say with a high degreee of certainty
that it's not going to happen.
Licensing is one issue. Tcl is currently used
in a lot of commercial software. Changing the
distribution terms from "BSD" to "mostly BSD,
but there are some LGPL bits in there now too"
would be seriously detrimental.
Then there's logistics. The Tcl maintainers should
not be, and for the most part do not want to be,
responsible for maintaining and distributing a third-party
package that's already a system library on the majority
of the platforms where it's supported.
Then there's portability. Cairo works on most
modern Unices, but Tcl works on (and still at least
nominally claims to support) a much broader range
of platforms, including older ones that would
take a *lot* of work to get Cairo working on
satisfactorily.
Lastly and most importantly: Tk atop Cairo sounds like
it would be a neat idea, but nobody's actually implemented
it yet nor does anyone appear to be working on it.
So it's kind of a pointless question.
--JE
Joe English
> Licensing is one issue. Tcl is currently used
> in a lot of commercial software. Changing the
> distribution terms from "BSD" to "mostly BSD,
> but there are some LGPL bits in there now too"
> would be seriously detrimental.
I should add: there is usually no problem with including
LGPLed code in commercial software.
*Getting approval from management* to include LGPLed code
in commercial software can be a *huge* problem.
--JE
Donal K. Fellows
> Heck, the code to print
> under Windows probably wouldn't even be linked into the executable for
> Unix versions of Tk.
On a simple level, of course it wouldn't be linked (or even compiled)
since it otherwise wouldn't be able to complete linking due to missing
Windows libraries... :-)
More generally, the problem is that Unix and Windows have fundamentally
different printing models, and their users have quite different
expectations too. Sorting this out is a big job, and involves work at
quite a large number of levels of Tk.
Donal.