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 <luc@sep.invalid> wrote:
> 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.

On Mon, 4 Mar 2024 03:06:07 -0000 (UTC), Rich wrote:

>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.

That is a large number of words I don't even understand.

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.

I have multiple text editors. Each one of them has the exact same "send
to printer" command. A Windows based text editor running on Wine has
that same command. An ancient dictionary, also for Windows running on
Wine, has that command. Image editors such as The Gimp have the same
command. PDF readers have that same command. All my browsers have that
command including an extremely old version of Opera I insist on not
throwing away.

I just tested some of these I mentioned, especially the Windows based
ones and the ancient Opera. They all work. I don't really print on
paper, my printer driver is set up to print to PDF. But they all
worked including fonts and colors.

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.

--
Luc
>>

Luc <luc@sep.invalid> wrote:
> 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.

They also all contain code, written by their various programmers, to
create the "data file" that goes 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.

Because, "print" is not a native built in. It is code you have to
write to create the "output" data that goes to the printer that
produces the "sheets of paper" (be they physical sheets, or virtual PDF
sheets).

You have to "translate" what you have in your text widget into the
proper output to create a "print".

On Sun, 3 Mar 2024 23:47:03 -0300, Luc wrote:

> 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?

I've sent it to a web browser in the past which works quite well. It's
not ideal but it does work and allows you to leverage a decent printer
engine. Unfortunately, even with that you can't make too many
assumptions, printing in Firefox can still be pretty hit or miss for
example.

Best wishes

Lorry

---
Modula-2 Compilers on CP/M
https://techtinkering.com/articles/modula-2-compilers-on-cpm/

Am 04.03.2024 um 03:47 schrieb Luc:
> 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?
>

Hi Luc,

so called "basic printing support" is implemented in Tk 8.7 and Tk 9.0
and prints a text widget.

Kevin Waltzer inversted a lot to make this happen.
The TIPs are:

https://www.tcl-lang.org/man/tcl9.0/TkCmd/print.html

Take care,
Harald

At Mon, 4 Mar 2024 03:06:07 -0000 (UTC) Rich <rich@example.invalid> wrote:

>
> Luc <luc@sep.invalid> wrote:
> > 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.

The pdf4tcl package can do this.

>
> 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.
>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

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?

--
Luc
>>

Luc <luc@sep.invalid> wrote:
> 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!

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.

> Even if I do that, what's with the coordinates?

That is how you position things on the paper. Printing is the act of
"placing" things onto a sheet of paper, and you have to tell the
printer "where" on the sheet you want the thing placed.

> How am I supposed to know the correct coordinates?

You have to compute them based upon where you want your output to end
up on the paper.

> Do paper and ink have pixels?

Yes, in a way (you can consider the coordinates to be "pixels"). The
coordinates (for pdf4tcl) if you don't change from the defaults,
default to "printers points" (1/72 of an inch).

> How do I calculate them?

By knowing the size of the sheet of paper you are building the output
for. You can then compute the coordinates as distances/lengths from
the origin (usually top left corner for pdf4tcl unless you change
things from the default).

> What paper size?

Whatever size you choose to use. PDF does not care. Although a PDF
formatted for a huge paper size will not print correctly on a smaller
physical sheet.

> I see I can set paper size, but how do I know what paper size the
> user has?

You have to ask.

> Do I have to write my own "Setup page" configuration dialog?

For full fledged printing, yes. Or you "pick a size" and just use that
and anyone else who wants something else just has to deal with that
fact.

> So I do and the user provides the information on paper size. Then
> what?

You use that size to compute the correct coordinates for where on the
user's sheet of paper you want various things to be printed.

"Printing" is very much an exercise in telling a machine (the printer)
the following:

at position 5,10 make a mark of an "T"
at position 5,22 make a mark of an "h"
at position 5,34 make a mark of an "e"

Numbers made up above. Note that in many cases you do get to do things
like:

at position 10,11 make these marks "The quick brown fox"

and the machine will drop toner/ink on the paper to make those letters
appear. You, however, still have to compute the 10,11 coordinates to
tell it where to begin.

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.

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. :-(

--
Luc
>>

Luc <luc@sep.invalid> wrote:
> 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.

The User Interface (UI) is orthogonal to the underlying effort of
formatting the data for printing. For Windows, the Windows OS provides
the user interface dialogs (which is why they all look identical). But
the individual applications still have to create the "data" which
Windows expects to receive in order to do a print.

> It is obvious that they are using some shared library that handles
> it the same way to all of them.

Don't measure the complexity from looking at the user interface window.
There is a huge amount of complexity hidden underneath that UI
wallpaper.

> What I really don't understand is why Tk can't reach out for the same
> library and use the same facilities.

Someone has to do that work to write that code so that Tk can do that.
So far, no volunteers with the necessary knowledge has created that for
Tk (other than what Harold indicates has been now created for 8.7).

> 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.

> 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. :-(

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).

On 3/4/2024 3:32 PM, Luc wrote:
> 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. :-(
>
>

Notwithstanding the challenges of printing, at least this will be
eco-friendly :-)

At Mon, 4 Mar 2024 15:47:39 -0300 Luc <luc@sep.invalid> wrote:

>
> 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!

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

>
> 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?

Yes, paper and ink have pixels. It is after all just another 2D graphic
medium. A printer just deposits dots on the paper, each dot is a pixel, just
as every pixel on your screen is a dot.

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.

For some example code doing all of this, have a look at my RolePlayingDB3,
source available for download at
https://www.deepsoft.com/home/products/roleplayingdb/downloadrpg/
Look in Scripts/RPGUtilities.tcl starting at the method outputXMLToPDF and the
methods it calls.

>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

At Mon, 4 Mar 2024 17:32:41 -0300 Luc <luc@sep.invalid> wrote:

>
> 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.

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
PDF) is actually more complex since it depends on whether you intent to
re-justify the text or not.

>
> 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. :-(
>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

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... :-(

--
Luc
>>

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.

--
Luc
>>

Luc <luc@sep.invalid> wrote:
> 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.

Yep. And for pdf4tcl, it provides a proc that can lay out text into a
box (but you have to pick the size of the box), saving you the trouble
of doing the same a character, or word, at a time.

But, it only works for a single font at a time. So for a line with
plural fonts on the same line, you have to "place" the parts using each
font individually, measuring how much space each took, and watching for
running off the far end yourself.

>>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?

I was not commenting on your ability (or my opinion thereof). I was
pointing out an alternative path.

> Maybe I should output HTML or RTF pages. That I could do. Sigh...
> :-(

In some ways, that could be simpler, esp. as it sounds like you've
never done any "render for printing" work. You can probably get
something close to what you want with HTML, and ignore the hard parts
of measuring lines and computing coordinates for "printing".

Luc <luc@sep.invalid> wrote:
> 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.

Typical single line spacing is 120% of the font's "lineheight" value.
Lineheight is a value you can ask about from the font itself. Once you
extract the lineheight you then can know how much "distance" to leave
between lines.

pdf4tcl also includes a proc that you can use to measure the width of a
group of characters when printed using a font. That can let you know
where you are horizontally on the sheet of paper, so you can avoid
falling off the edge.

None of it is "rocket science" or "calculus", and most of the math
involved is the basic grade school four of add, subtract, multiply, and
divide.

What makes it complex is it is a huge number of little bits to
accurately keep track of, and a number of other decisions to make
as to what you want to do given different things that happen. All that
makes it complicated and messy. And if you've never done any of it
before, it looks almost inscrutable.

> 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.

The same way you'd do it if you were using canvas. You'd 'measure' the
strings, and decide where they go (or if they need to be broken) based
on their size. Only here, instead of 'pixels' you get lengths (mm, cm,
inch, point, pick your poison).

> 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:

>> 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.

--
Luc
>>

On 3/4/2024 6:36 PM, Luc wrote:
> On Mon, 4 Mar 2024 23:12:21 -0000 (UTC), Rich wrote:
>

Can you share a screenshot of your screen / what you are talking about?

There may be other options that could make printing easy.

Luc <luc@sep.invalid> 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.

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.

At Mon, 4 Mar 2024 19:19:43 -0300 Luc <luc@sep.invalid> wrote:

>
> 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.

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).

>
>
> 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.

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).

Doing screen captures of text widget is a really dumb idea.

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.

>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

On Mon, 4 Mar 2024 18:40:30 -0500, saitology9 wrote:

>Can you share a screenshot of your screen / what you are talking about?
>
>There may be other options that could make printing easy.

Don't worry. I will be publishing the whole application in a few days.
You will see what it's about.

--
Luc
>>

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.

--
Luc
>>

On Tue, 05 Mar 2024 01:55:04 +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.
>
>(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).

The way you describe sounds interesting indeed. I will look into it.
But I will save it for last.

>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).

That is good to know. Thank you.

>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.

I am saving this message for later reference. I will look into the
method you are describing. Thank you.

--
Luc
>>