Yeah, well, I naively assumed that printing the content of my text
widget in 2024 would easy peasy, piece of cake, a done deal,
But it seems that printing in anything except Windows is very very difficult.
Mind you, my text widget has formatting. More specifically, a large
number of different fonts.
So I considered the most obvious alternative: exporting to PDF.
But that is not very much accomplished either. All solutions I found
can only export to ASCII not Unicode (that is tolerable but bad) and
I am not entirely confident they will support the wide range of fonts.
So what are my options here? Do I really have any?
Generate a PDF. Most likely to be usable everywhere.
Generate PostScript. More useful on Linux and maybe Mac than on
Windows.
Generate some other 'formatting' language (LaTeX, Troff, Markdown,
etc.) and then render that to PDF/print.
Generate the native "printer control language" for a given printer
(ties you to just that printer -- or to having to create plural
modules, one per printer you want support).
None will be a drop in, call one command with a few options like paper
size and so forth set and go. Most will require you to either become a >"typesetter" (the PDF/Postscript/direct printer control route) or to
learn enough about the formatting language to generate what you want
via it as intermediary.
The closest you'll get from built in basic Tcl/Tk is to 'render' what
you want to print on a canvas widget, then use the export to postscript >option of the canvas to get postscript of the widget. Which you can
then convert to PDF with Ghostscript if you want a pdf. But that last
step requires Ghostscript be available, and on windows it will be
uncommon to find it already installed.
Most - almost all really - programs I have on my Linux box have a Print command. Even the email program I'm using to read this group. I could
just press Ctrl+p and print your message.
They just send it to the printer.
Why is it so hard for Tk? Why can't it just "send to printer" like
all these applications do? I doubt any of them goes through all the
high and narrow hoops you described.
Yeah, well, I naively assumed that printing the content of my text
widget in 2024 would easy peasy, piece of cake, a done deal, just a
command and maybe two options, but after reading the manual and the wiki
I was very surprised to find out that printing in Tcl/Tk is still more
of a wish list item than a real feature.
And I wanted this application to be very platform agnostic, running on
Linux, Windows, BSD and possibly Mac.
[SNIP]
So what are my options here? Do I really have any?
Yeah, well, I naively assumed that printing the content of my text
widget in 2024 would easy peasy, piece of cake, a done deal, just a
command and maybe two options, but after reading the manual and the
wiki I was very surprised to find out that printing in Tcl/Tk is still
more of a wish list item than a real feature.
And I wanted this application to be very platform agnostic, running on
Linux, Windows, BSD and possibly Mac.
But it seems that printing in anything except Windows is very very
difficult.
Mind you, my text widget has formatting. More specifically, a large
number of different fonts.
So I considered the most obvious alternative: exporting to PDF.
But that is not very much accomplished either. All solutions I found
can only export to ASCII not Unicode (that is tolerable but bad) and
I am not entirely confident they will support the wide range of fonts.
So what are my options here? Do I really have any?
Luc <luc@sep.invalid> wrote:The pdf4tcl package can do this.
Yeah, well, I naively assumed that printing the content of my text
widget in 2024 would easy peasy, piece of cake, a done deal,
Nope, not at all. "Printing" is a whole other set of issues.
But it seems that printing in anything except Windows is very very difficult.
It is not easy even in windows.
Mind you, my text widget has formatting. More specifically, a large
number of different fonts.
So I considered the most obvious alternative: exporting to PDF.
But that is not very much accomplished either. All solutions I found
can only export to ASCII not Unicode (that is tolerable but bad) and
I am not entirely confident they will support the wide range of fonts.
If you have truetype font files that contain the glyphs you want to
output, then exporting to PDF can produce the entire Unicode character
set. But that too requires some juggling on your part. See the recent thread here in the group on the two different PDF generation libraries
for Tcl.
So what are my options here? Do I really have any?
Generate a PDF. Most likely to be usable everywhere.
Generate PostScript. More useful on Linux and maybe Mac than on
Windows.
Generate some other 'formatting' language (LaTeX, Troff, Markdown,
etc.) and then render that to PDF/print.
Generate the native "printer control language" for a given printer
(ties you to just that printer -- or to having to create plural
modules, one per printer you want support).
None will be a drop in, call one command with a few options like paper
size and so forth set and go. Most will require you to either become a "typesetter" (the PDF/Postscript/direct printer control route) or to
learn enough about the formatting language to generate what you want
via it as intermediary.
The closest you'll get from built in basic Tcl/Tk is to 'render' what
you want to print on a canvas widget, then use the export to postscript option of the canvas to get postscript of the widget. Which you can
then convert to PDF with Ghostscript if you want a pdf. But that last
step requires Ghostscript be available, and on windows it will be
uncommon to find it already installed.
The pdf4tcl package can do this.
On Mon, 04 Mar 2024 12:19:50 +0000, Robert Heller wrote:
The pdf4tcl package can do this.
It doesn't suit me.
The documentation says:
pdf4tcl::new mypdf -paper a3
mypdf startPage
mypdf setFont 12 Courier
mypdf text "Hejsan" -x 50 -y 50
mypdf write -file mypdf.pdf
mypdf destroy
That works, but as soon as I change the font to Freesans it throws an
error saying the Freesans font doesn't exist.
If I understand the documentation correctly, I will have to manually
"load" each font from its font file located in /usr/share/fonts.
That's surprisingly low level!
Even if I do that, what's with the coordinates?
How am I supposed to know the correct coordinates?
Do paper and ink have pixels?
How do I calculate them?
What paper size?
I see I can set paper size, but how do I know what paper size the
user has?
Do I have to write my own "Setup page" configuration dialog?
So I do and the user provides the information on paper size. Then
what?
And now you begin to see what I stated in the message you said you
did not fully understand. Yes, it is that low level.
On Mon, 4 Mar 2024 19:01:16 -0000 (UTC), Rich wrote:
And now you begin to see what I stated in the message you said you
did not fully understand. Yes, it is that low level.
I fully understand. I don't believe it, that's different.
I don't believe that all the applications I have here, including some
pretty old and frumpy ones, can print so easily, always with the same
Print and Print/Page Setup commands.
It is obvious that they are using some shared library that handles
it the same way to all of them.
What I really don't understand is why Tk can't reach out for the same
library and use the same facilities.
Meanwhile, I'm trying to convert my text widget to png and maybe one
of the PDF extensions will render it with a lot less hassle. Look,
extension. It's an image, mmkay? Don't ask me about fonts, sizes and coordinates. Just render the image.
Apparently capturing an entire text widget to an image is not easy
either if possible at all. Maybe I'll just have to completely give up
on the idea of printing. :-(
On Mon, 4 Mar 2024 19:01:16 -0000 (UTC), Rich wrote:
Apparently capturing an entire text widget to an image is not easy
either if possible at all. Maybe I'll just have to completely give up
on the idea of printing. :-(
On Mon, 04 Mar 2024 12:19:50 +0000, Robert Heller wrote:No, not really... If you want to see truly low level grovel through the *Printer.h and *Printer.cc files in https://github.com/RobertPHeller/ModelRRSystem/tree/master/trunk/C%2B%2B/FCFSupport
The pdf4tcl package can do this.
It doesn't suit me.
The documentation says:
pdf4tcl::new mypdf -paper a3
mypdf startPage
mypdf setFont 12 Courier
mypdf text "Hejsan" -x 50 -y 50
mypdf write -file mypdf.pdf
mypdf destroy
That works, but as soon as I change the font to Freesans it throws an
error saying the Freesans font doesn't exist.
If I understand the documentation correctly, I will have to manually
"load" each font from its font file located in /usr/share/fonts.
That's surprisingly low level!
Even if I do that, what's with the coordinates? How am I supposed toYes, paper and ink have pixels. It is after all just another 2D graphic
know the correct coordinates? Do paper and ink have pixels? How do I calculate them? What paper size? I see I can set paper size, but how
do I know what paper size the user has? Do I have to write my own
"Setup page" configuration dialog? So I do and the user provides
the information on paper size. Then what?
On Mon, 4 Mar 2024 19:01:16 -0000 (UTC), Rich wrote:
And now you begin to see what I stated in the message you said you
did not fully understand. Yes, it is that low level.
I fully understand. I don't believe it, that's different.Creating the dialog boxes is trivial (that is actually the "easy" part). Tk *does* provide a way to convert a canvas widget into a postscript file (or stream) and has since forever. Converting a text widget to postscript (or
I don't believe that all the applications I have here, including some
pretty old and frumpy ones, can print so easily, always with the same
Print and Print/Page Setup commands.
It is obvious that they are using some shared library that handles
it the same way to all of them.
What I really don't understand is why Tk can't reach out for the same
library and use the same facilities.
Well, as our fellow group user Harald has pointed out, it seems that something like that has been implemented in Tk 8.7 and Tk 9.0. It's
good news.
Still a bit of a problem because I can't expect users to have Tk 8.7
or Tk 9.0 installed just yet. That is going to take a while.
And I seriously intended to support 32-bit 9.x Windows using an old
version of Freewrap I have here. I'm afraid that is just not going to
happen. :-(
Meanwhile, I'm trying to convert my text widget to png and maybe one
of the PDF extensions will render it with a lot less hassle. Look,
extension. It's an image, mmkay? Don't ask me about fonts, sizes and coordinates. Just render the image.
Apparently capturing an entire text widget to an image is not easy
either if possible at all. Maybe I'll just have to completely give up
on the idea of printing. :-(
Meanwhile, I'm trying to convert my text widget to png and maybe one
of the PDF extensions will render it with a lot less hassle. Look,
extension. It's an image, mmkay? Don't ask me about fonts, sizes and
coordinates. Just render the image.
You'll still have to worry about coordinates, because you'll need to
decide where on the page you want the png to appear.
Or expend effort to write the code to convert what is on screen in the
text widget to a PDF, and output the PDF (then you can ignore the
actual "printing" part and let a user's PDF viewer handle that for when
they actually want a hard copy).
You have two main options: pick some paper size (say Letter or A4) and use >that and the user can "lump it" or provide a "Setup page" configuration >dialog and give the user a selection and use that. You can use >::pdf4tcl::getPaperSizeList to populate the paper size dropdown (or use a >subset), then later use ::pdf4tcl::getPaperSize to get the size of the >selected paper. This gives you the max X (width) and Y (height) of the
page. Then you just need to maintain a set of vars for the current
position. The only really tricky bit is handling line overflow and >justification.
On Mon, 4 Mar 2024 20:46:18 -0000 (UTC), Rich wrote:
Meanwhile, I'm trying to convert my text widget to png and maybe one
of the PDF extensions will render it with a lot less hassle. Look,
extension. It's an image, mmkay? Don't ask me about fonts, sizes and
coordinates. Just render the image.
You'll still have to worry about coordinates, because you'll need to >>decide where on the page you want the png to appear.
An image is just one big block so deciding on its coordinates should
not be hard. The problem is printing lines of text. Remember I said
in another thread that some fonts take more space than others and I
was struggling to make all of them fit in the private boxes. It's
more or less the same problem again.
Or expend effort to write the code to convert what is on screen in
the text widget to a PDF, and output the PDF (then you can ignore the >>actual "printing" part and let a user's PDF viewer handle that for
when they actually want a hard copy).
Man, you've seen me struggle with threads, namespaces, even fonts in
a text widget. What makes you think I have any clue about writing
code to convert anything to PDF?
Maybe I should output HTML or RTF pages. That I could do. Sigh...
:-(
On Mon, 04 Mar 2024 20:55:38 +0000, Robert Heller wrote:
You have two main options: pick some paper size (say Letter or A4) and use >>that and the user can "lump it" or provide a "Setup page" configuration >>dialog and give the user a selection and use that. You can use >>::pdf4tcl::getPaperSizeList to populate the paper size dropdown (or use a >>subset), then later use ::pdf4tcl::getPaperSize to get the size of the >>selected paper. This gives you the max X (width) and Y (height) of the >>page. Then you just need to maintain a set of vars for the current >>position. The only really tricky bit is handling line overflow and >>justification.
Believe it or not (I won't be offended if you don't), I sort of had
figured all that out by myself. To me, the really tricky bit though is figuring out how many "pixels" (dpi?) there should be between lines.
Some fonts take more space than others. Possibly A LOT more than others.
I find that very challenging. I don't even know where to begin.
I've been toying with another idea.
10 Convert the visible part of the text widget to png.
20 Scroll down one pageful.
30 IF EOF BREAK;
40 GOTO 10
But then I guess I would have to depend on ImageMagick. There is no
mention of such capability in the Tcl/Tk manual.
I've been toying with another idea.
10 Convert the visible part of the text widget to png.
20 Scroll down one pageful.
30 IF EOF BREAK;
40 GOTO 10
But then I guess I would have to depend on ImageMagick. There is no
mention of such capability in the Tcl/Tk manual.
That would get you plural PNG's, you then have to get the PNG's
"printed" somehow (either by generating a PDF or by wrapping them with
some HTML and letting a browser do the "generate" for you).
On Mon, 4 Mar 2024 23:12:21 -0000 (UTC), Rich wrote:
On Mon, 4 Mar 2024 23:12:21 -0000 (UTC), Rich wrote:
I've been toying with another idea.
10 Convert the visible part of the text widget to png.
20 Scroll down one pageful.
30 IF EOF BREAK;
40 GOTO 10
But then I guess I would have to depend on ImageMagick. There is no
mention of such capability in the Tcl/Tk manual.
That would get you plural PNG's, you then have to get the PNG's
"printed" somehow (either by generating a PDF or by wrapping them with >>some HTML and letting a browser do the "generate" for you).
Sorry, I wasn't properly clear. My fault.
The capability I mentioned that would require ImageMagick is merging
a bunch of png files into one. Merging is the crucial bit of
information I accidentally left out.
Then maybe I could use one of the PDF extensions to convert the merged
result to PDF.
On Mon, 04 Mar 2024 20:55:38 +0000, Robert Heller wrote:Actually, it is not really that hard. pdf4tcl takes care of most of that. pdf4tcl has a newLine method, which advances the y coordinate by the proper amount for the current font's line height and returns the x coordinate to the value of the left margin value (set when the page is initialized). You only need to keep track of when you get to the bottom of the page and need to start a new one. Something like y + linespacing, where linespacing is some function of the font size. When y gets close to the bottom margin, you start a new page and reset the line count and y value and continue.
You have two main options: pick some paper size (say Letter or A4) and use >that and the user can "lump it" or provide a "Setup page" configuration >dialog and give the user a selection and use that. You can use >::pdf4tcl::getPaperSizeList to populate the paper size dropdown (or use a >subset), then later use ::pdf4tcl::getPaperSize to get the size of the >selected paper. This gives you the max X (width) and Y (height) of the >page. Then you just need to maintain a set of vars for the current >position. The only really tricky bit is handling line overflow and >justification.
Believe it or not (I won't be offended if you don't), I sort of had
figured all that out by myself. To me, the really tricky bit though is figuring out how many "pixels" (dpi?) there should be between lines.
Some fonts take more space than others. Possibly A LOT more than others.
I find that very challenging. I don't even know where to begin.
I've been toying with another idea.Converting to PNG will end up looking terrible. Print resolution is higher than screen resolution (printers can do 300-600 dpi and screen res in like 75 or 100 dpi). Modern fonts use vector graphics (and are scalable across
10 Convert the visible part of the text widget to png.
20 Scroll down one pageful.
30 IF EOF BREAK;
40 GOTO 10
But then I guess I would have to depend on ImageMagick. There is no
mention of such capability in the Tcl/Tk manual.
Can you share a screenshot of your screen / what you are talking about?
There may be other options that could make printing easy.
Unless the merged image fits on a single sheet of paper (or you are ok
with shrinking it to fit) an image that is too large has to be split
up, by you the programmer, before being placed onto the output "pages". >Pdf4tcl will shrink it to fit for you, but it will not break a single
image up into page size chunks.
Actually, it is not really that hard. pdf4tcl takes care of most of that. >pdf4tcl has a newLine method, which advances the y coordinate by the proper >amount for the current font's line height and returns the x coordinate to
the value of the left margin value (set when the page is initialized). You >only need to keep track of when you get to the bottom of the page and need
to start a new one. Something like y + linespacing, where linespacing is
some function of the font size. When y gets close to the bottom margin,
you start a new page and reset the line count and y value and continue.
(Look at the code in my Role Playing DB's print code to see how that is >done.)
There is a function in the pdf4tcl package which computes how much space
(in pixels) a given string will take up. This function can both be used
to check if a given string will fit on a line horizontally and/or
vertically or even to get a font's metrics (how wide and tall a font is).
Converting to PNG will end up looking terrible. Print resolution is
higher than screen resolution (printers can do 300-600 dpi and screen res
in like 75 or 100 dpi). Modern fonts use vector graphics (and are
scalable across various sizes and resolutions).
It is not *really* that hard to just do a [.text get 1.0 end-1c] to
capture the text and then iterating over the text and doing pdf4tcl's text >write method to "print" it to a PDF file. If your text is using various >"styles", you'll have to do the .text get's piecemeal and fetch the style >settings to pass along to the pdf4tcl methods. More complicated, but
hardly impossible. The additional "work" will pay off in the end with a
high quality result.
On Tue, 5 Mar 2024 00:15:56 -0000 (UTC), Rich wrote:
Unless the merged image fits on a single sheet of paper (or you are ok
with shrinking it to fit) an image that is too large has to be split
up, by you the programmer, before being placed onto the output "pages".
Pdf4tcl will shrink it to fit for you, but it will not break a single
image up into page size chunks.
Another point in favor of the RTF format. A word processor can handle automatic page breaks very well.
I will add RTF.
Another possibility is to generate HTML and use wkhtmltopdf (available
on Windows and Linux) to generate PDF. No need for coordinates, pixels,
line and page breaks, and the likes.
HTH.
On Tue, 5 Mar 2024 09:06:34 +0100, Manuel Collado wrote:
Another possibility is to generate HTML and use wkhtmltopdf (available
on Windows and Linux) to generate PDF. No need for coordinates, pixels, >>line and page breaks, and the likes.
HTH.
Interesting addition to my personal toolbox, but I probably can't
include and distribute it because it's licensed under the LGPLv3 and
my application is licensed under BSD terms.
If you make no changes to it (wkhtmltopdf) and supply the licence file
for it as well, there should be no issues with you distributing it.
Given that all you'd be doing is using it the same as any other end
user (launching it with an html input file) there is likely no issue.
Bundling it, in its own sub-directory, unmodified, with your bundle
should not cause your code to need to be relicenced. And if your
entire interface is "exec wkhtmltopdf /tmp/htmlfile" you are not adding
any of it into any of your source files.
If you want to be more 'careful' then supply it as a second,
dependency, tar/zip file that has to also be installed for your code to >work. Then it is not part of your "bundle" at all.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 915 |
| Nodes: | 10 (2 / 8) |
| Uptime: | 44:04:15 |
| Calls: | 12,170 |
| Calls today: | 2 |
| Files: | 186,521 |
| Messages: | 2,234,544 |