Greetings all;
As has been mentioned, I dabble in CNC machinery too. Maybe that qualifies me as a power user since the motors used to run the machinery do spin the power meter up a bit. :)
Anyway, the most recent version of the documentation for LiniuxCNC, version 2.7.0, has been combined from 3 "books" of nominally 450 pages each, some of which contained duplicate info, into one 704 page tome now.
So I called up kpdf and sent it to print this, duplex mode on my Brother HL3170CDW color laser printer.
It immediately jumped one core to 100%, but I figured that would take it a while to preprocess. But after about 10 minutes I began to worry because I had started that job once before but had to reboot the machine for other reasons before it had sent a wakeup byte to the printer.
So I called up a copy of iceweasel to see what localhost:631/printers/network-printer had to say for itself. Which was that the "pdftops" filter had failed.
So I canceled the job. Thirty seconds later, the printer wakes up and starts slowly spitting out the printout as requested. But I have no clue how many pages into the document it will get before running out of data because it is about 30 sheets of paper into the job, and still trucking along in duplex mode. The printer is rated at 20 PPM, but in duplex, all that paper handling cuts it to about 2 or 3 sheets a minute.
When it dies, I can restart the job at an arbitrary page number to finish the job of course, but I am curious why the web interface to cups would report the failure of the pdftops filter, yet it looks to be working well right this instant?
But then it reported a drum error, please slide the wire cleaner gismo's on all 4 drums. Did, it spit out the bad page and reprinted a good copy of that page. And 34 pages of preamble index etc, plus over 100 pages of the 704 in the doc so far. Did I mention I love Brother printers yet?
But whats with kpdf? Inquiring minds would like to know.
Thanks everybody.
Cheers, Gene Heskett
On Saturday 12 September 2015 17:32:48 Gene Heskett wrote:
Greetings all;
As has been mentioned, I dabble in CNC machinery too. Maybe that qualifies me as a power user since the motors used to run the machinery do spin the power meter up a bit. :)
Anyway, the most recent version of the documentation for LiniuxCNC, version 2.7.0, has been combined from 3 "books" of nominally 450 pages each, some of which contained duplicate info, into one 704 page tome now.
So I called up kpdf and sent it to print this, duplex mode on my Brother HL3170CDW color laser printer.
It immediately jumped one core to 100%, but I figured that would take it a while to preprocess. But after about 10 minutes I began to worry because I had started that job once before but had to reboot the machine for other reasons before it had sent a wakeup byte to the printer.
So I called up a copy of iceweasel to see what localhost:631/printers/network-printer had to say for itself. Which was that the "pdftops" filter had failed.
This is 6 years old: http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_st...
Why do you need a filter to print pdf? Is it because your printer is very old? Do you know? Does anyone else?
Lisi
So I canceled the job. Thirty seconds later, the printer wakes up and starts slowly spitting out the printout as requested. But I have no clue how many pages into the document it will get before running out of data because it is about 30 sheets of paper into the job, and still trucking along in duplex mode. The printer is rated at 20 PPM, but in duplex, all that paper handling cuts it to about 2 or 3 sheets a minute.
When it dies, I can restart the job at an arbitrary page number to finish the job of course, but I am curious why the web interface to cups would report the failure of the pdftops filter, yet it looks to be working well right this instant?
But then it reported a drum error, please slide the wire cleaner gismo's on all 4 drums. Did, it spit out the bad page and reprinted a good copy of that page. And 34 pages of preamble index etc, plus over 100 pages of the 704 in the doc so far. Did I mention I love Brother printers yet?
But whats with kpdf? Inquiring minds would like to know.
Thanks everybody.
Cheers, Gene Heskett
On Saturday 12 September 2015 13:38:00 Lisi Reisz wrote:
On Saturday 12 September 2015 17:32:48 Gene Heskett wrote:
Greetings all;
As has been mentioned, I dabble in CNC machinery too. Maybe that qualifies me as a power user since the motors used to run the machinery do spin the power meter up a bit. :)
Anyway, the most recent version of the documentation for LiniuxCNC, version 2.7.0, has been combined from 3 "books" of nominally 450 pages each, some of which contained duplicate info, into one 704 page tome now.
So I called up kpdf and sent it to print this, duplex mode on my Brother HL3170CDW color laser printer.
It immediately jumped one core to 100%, but I figured that would take it a while to preprocess. But after about 10 minutes I began to worry because I had started that job once before but had to reboot the machine for other reasons before it had sent a wakeup byte to the printer.
So I called up a copy of iceweasel to see what localhost:631/printers/network-printer had to say for itself. Which was that the "pdftops" filter had failed.
This is 6 years old: http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf _as_standard_print_job_format
Why do you need a filter to print pdf? Is it because your printer is very old?
It was still on the shelf at Staples Office Supply a year ago, so its not truly ancient like me, yet.
Do you know?
I bought it new about 2 years ago. It has now logged something over 4000 pages.
Does anyone else?
Unk, no clue who might have one of these locally. Everyone else is using inkjets, at 4x the cost per page printed.
The filter is primarily because in order for the current gs to print it, there needs to be a translation between a pdf and a ps. In any event, I may have found the source of the reported error, there were a total of 7 images in that file that were rendered, both onscreen and on paper as solid black in the shape of the expected image. I have reported the page numbers where this occurred, but haven't heard back from the doc's compiler yet.
Other than that, the whole thing printed with only 3 orange led blink sessions, 2 notices to clean the static wires on all 4 drums, and ran out of paper once. I have it punched and mounted in a 2.5" ring 3 ring binder already.
Lisi
Thanks Lisi.
Cheers, Gene Heskett
On Saturday 12 September 2015 23:28:46 Gene Heskett wrote:
The filter is primarily because in order for the current gs to print it, there needs to be a translation between a pdf and a ps.
Thanks, Gene. But my question was why?? Why does it have to be translated?
Lisi
On Sunday 13 September 2015 06:17:04 Lisi Reisz wrote:
On Saturday 12 September 2015 23:28:46 Gene Heskett wrote:
The filter is primarily because in order for the current gs to print it, there needs to be a translation between a pdf and a ps.
Thanks, Gene. But my question was why?? Why does it have to be translated?
Lisi
GS, aka Ghostscript, back in v5 days, had a very good pdf level 2 renderer. It was also hell to compile, I did it twice on a big box amiga in the '90's.
Somewhere along the line, someone decided the best way to handle the bloat was to excise the pdf stuffs from ghostscript and let it concentrate on postscript only. Hence the need for a pipeing filter, called pdftops, to translate and expand the pdf into postscript that gs understands.
Both are random access file formats, but pdf uses a second lookup depth I haven't fully understood, and that must be translated and piped into gs as pure postscript.
FWIW, a properly done Level 3 pdf is the ultimate file compression when applied to a large document. This particular file that generates a 740 page, with lots of graphics, manual is just north of 121 megabytes. By the time pdftops has unpacked it and sent it to gs, it is still quite conmpressed, but the translation makes about 546 megabytes that gets sent over the pipe to gs. The resultant data that flows down the cat5 (or the slower USB if your printer doesn't have a network presence) to the printer is probably in excess of 5 terrabytes.
In the old days, I did not have a duplex capable printer, so I would command gs to make a file per page, then wrote an arexx script to send all odd pages to the printer, then when that was done, turn the pile over and then then send all the even numbered pages. But that filled up a 1Gb seagate drive , so had to be cleaned up if I wanted to do it to a different big pdf, else it was out of disk.
But I had to make the arexx script check the file size, and if it was under 100 bytes, it was nothing but the setup and teardown for the page, so rather than send that file to the printer, which if it was sitting at TOF, ignored a formfeed, so I sent it a line feed to get it off of TOF position, then the formfeed, which would eject the desired blank page, keeping the printout in the order desired, even for a 500+ page document. Without that, the binding ditch was fubar. Thats the space at the left edge of an odd page, or the right edge of an even page where a wider margin is used so the 3 hole punch misses the text.
I had an extended, and fruitless discussion with the gs maintainer at the time who couldn't conceive of a printer ignoring a formfeed if it was sitting at the top of the page already, but every Merican printer I ever had did ignore it including a couple Brother Daisy wheelers. Writing the arexx script was less hassle than trying to convince that person that he needed to add one linefeed byte in front of the formfeed. Sigh...
Your daily dose of ancient ghsotscript trivia. ;-)
Cheers Lisi, Gene Heskett
On Sunday 13 September 2015, Gene Heskett wrote:
On Sunday 13 September 2015 06:17:04 Lisi Reisz wrote:
On Saturday 12 September 2015 23:28:46 Gene Heskett wrote:
The filter is primarily because in order for the current gs to print it, there needs to be a translation between a pdf and a ps.
Thanks, Gene. But my question was why?? Why does it have to be translated?
Lisi
GS, aka Ghostscript, back in v5 days, had a very good pdf level 2 renderer. It was also hell to compile, I did it twice on a big box amiga in the '90's.
Somewhere along the line, someone decided the best way to handle the bloat was to excise the pdf stuffs from ghostscript and let it concentrate on postscript only. Hence the need for a pipeing filter, called pdftops, to translate and expand the pdf into postscript that gs understands.
Both are random access file formats, but pdf uses a second lookup depth I haven't fully understood, and that must be translated and piped into gs as pure postscript.
FWIW, a properly done Level 3 pdf is the ultimate file compression when applied to a large document. This particular file that generates a 740 page, with lots of graphics, manual is just north of 121 megabytes. By the time pdftops has unpacked it and sent it to gs, it is still quite conmpressed, but the translation makes about 546 megabytes that gets sent over the pipe to gs. The resultant data that flows down the cat5 (or the slower USB if your printer doesn't have a network presence) to the printer is probably in excess of 5 terrabytes.
In the old days, I did not have a duplex capable printer, so I would command gs to make a file per page, then wrote an arexx script to send all odd pages to the printer, then when that was done, turn the pile over and then then send all the even numbered pages. But that filled up a 1Gb seagate drive , so had to be cleaned up if I wanted to do it to a different big pdf, else it was out of disk.
But I had to make the arexx script check the file size, and if it was under 100 bytes, it was nothing but the setup and teardown for the page, so rather than send that file to the printer, which if it was sitting at TOF, ignored a formfeed, so I sent it a line feed to get it off of TOF position, then the formfeed, which would eject the desired blank page, keeping the printout in the order desired, even for a 500+ page document. Without that, the binding ditch was fubar. Thats the space at the left edge of an odd page, or the right edge of an even page where a wider margin is used so the 3 hole punch misses the text.
I had an extended, and fruitless discussion with the gs maintainer at the time who couldn't conceive of a printer ignoring a formfeed if it was sitting at the top of the page already, but every Merican printer I ever had did ignore it including a couple Brother Daisy wheelers. Writing the arexx script was less hassle than trying to convince that person that he needed to add one linefeed byte in front of the formfeed. Sigh...
Your daily dose of ancient ghsotscript trivia. ;-)
Cheers Lisi, Gene Heskett
That explains a lot. Thank you for the history lesson.
Kate
On Sunday 13 September 2015 11:30:09 Kate Draven wrote:
On Sunday 13 September 2015, Gene Heskett wrote:
On Sunday 13 September 2015 06:17:04 Lisi Reisz wrote:
On Saturday 12 September 2015 23:28:46 Gene Heskett wrote:
The filter is primarily because in order for the current gs to print it, there needs to be a translation between a pdf and a ps.
Thanks, Gene. But my question was why?? Why does it have to be translated?
Lisi
GS, aka Ghostscript, back in v5 days, had a very good pdf level 2 renderer. It was also hell to compile, I did it twice on a big box amiga in the '90's.
Somewhere along the line, someone decided the best way to handle the bloat was to excise the pdf stuffs from ghostscript and let it concentrate on postscript only. Hence the need for a pipeing filter, called pdftops, to translate and expand the pdf into postscript that gs understands.
Both are random access file formats, but pdf uses a second lookup depth I haven't fully understood, and that must be translated and piped into gs as pure postscript.
FWIW, a properly done Level 3 pdf is the ultimate file compression when applied to a large document. This particular file that generates a 740 page, with lots of graphics, manual is just north of 121 megabytes. By the time pdftops has unpacked it and sent it to gs, it is still quite conmpressed, but the translation makes about 546 megabytes that gets sent over the pipe to gs. The resultant data that flows down the cat5 (or the slower USB if your printer doesn't have a network presence) to the printer is probably in excess of 5 terrabytes.
In the old days, I did not have a duplex capable printer, so I would command gs to make a file per page, then wrote an arexx script to send all odd pages to the printer, then when that was done, turn the pile over and then then send all the even numbered pages. But that filled up a 1Gb seagate drive , so had to be cleaned up if I wanted to do it to a different big pdf, else it was out of disk.
But I had to make the arexx script check the file size, and if it was under 100 bytes, it was nothing but the setup and teardown for the page, so rather than send that file to the printer, which if it was sitting at TOF, ignored a formfeed, so I sent it a line feed to get it off of TOF position, then the formfeed, which would eject the desired blank page, keeping the printout in the order desired, even for a 500+ page document. Without that, the binding ditch was fubar. Thats the space at the left edge of an odd page, or the right edge of an even page where a wider margin is used so the 3 hole punch misses the text.
I had an extended, and fruitless discussion with the gs maintainer at the time who couldn't conceive of a printer ignoring a formfeed if it was sitting at the top of the page already, but every Merican printer I ever had did ignore it including a couple Brother Daisy wheelers. Writing the arexx script was less hassle than trying to convince that person that he needed to add one linefeed byte in front of the formfeed. Sigh...
Your daily dose of ancient ghsotscript trivia. ;-)
Cheers Lisi, Gene Heskett
That explains a lot. Thank you for the history lesson.
Kate
NP Kate & thanks for the flowers. I guess this is one thing us old farts are good for. But as I approach the 81st here in a couple weeks, I just got my cumuppance at assuming I am the oldest in any one mailing list. I found out yesterday that one lady whose pithy pronouncements I have been reading on another list, was in high school in 1929, so she has to be something in the 100 yo territory. And still as sharp as a whole box of carpet tacks too.
But, while the subject line is still somewhat on topic, I am about to nuke kpdf if the package manager will let me.
Neither okular & evince (usually called "Document viewer" in the menu's, like its supposed to be a big secret or something) do not have such a problem. okular, started from a cli, spits out several little red wagon loads of squawks, but works anyway, better than evince IMO.
Can a squawk be filed against kpdf?
The non-rendered images were in fact png's, possibly generated by a previous, maybe buggy?, version of a png maker as those images have in fact been around for most of a decade that I am aware of.
So if I can convince the printer dialog to print the correct 2 pages, in about 7 places in this book then I can replace just the bad pages in my 738 page book.
Cheers, Gene Heskett
On Sunday 13 September 2015 11:11:35 am Gene Heskett wrote:
But, while the subject line is still somewhat on topic, I am about to nuke kpdf if the package manager will let me.
Neither okular & evince (usually called "Document viewer" in the menu's, like its supposed to be a big secret or something) do not have such a problem. okular, started from a cli, spits out several little red wagon loads of squawks, but works anyway, better than evince IMO.
Can a squawk be filed against kpdf?
Sure,
KPDF is showing its age, as are some of the other old KDE apps.
I use evince here, okular has more features, and they work well for someone who uses them daily..or has a better memory. I prefer apps do do a few less tasks and do them well.
Some tool in my pdf 'toolbox' is pdftk, pdfshuffler, gs with the 'pdrwrite' option, mupdf, xournal, master-pdf-editor: great tools but free beer or pay only.
I have been working with fillable pdf forms, only because the other person doing it uses an Adobe product theat uses XFA 'enhancements', which no Free software pdf viewer supports, it is not a published standard or spec.
Evince and Okular can do X/FDF fillable forms, For Okular I have to google to find the feature to enable it, Evince just works, KPDF does not do fillable forms.
Greg M
On Monday 14 September 2015 00:41:04 Greg Madden wrote:
On Sunday 13 September 2015 11:11:35 am Gene Heskett wrote:
But, while the subject line is still somewhat on topic, I am about to nuke kpdf if the package manager will let me.
Neither okular & evince (usually called "Document viewer" in the menu's, like its supposed to be a big secret or something) do not have such a problem. okular, started from a cli, spits out several little red wagon loads of squawks, but works anyway, better than evince IMO.
Can a squawk be filed against kpdf?
Sure,
KPDF is showing its age, as are some of the other old KDE apps.
I use evince here, okular has more features, and they work well for someone who uses them daily..or has a better memory. I prefer apps do do a few less tasks and do them well.
Some tool in my pdf 'toolbox' is pdftk, pdfshuffler, gs with the 'pdrwrite' option, mupdf, xournal, master-pdf-editor: great tools but free beer or pay only.
I have been working with fillable pdf forms, only because the other person doing it uses an Adobe product theat uses XFA 'enhancements', which no Free software pdf viewer supports, it is not a published standard or spec.
Evince and Okular can do X/FDF fillable forms, For Okular I have to google to find the feature to enable it, Evince just works, KPDF does not do fillable forms.
I almost always use Evince now.
Lisi
On Sunday 13 September 2015 15:11:07 Gene Heskett wrote:
On Sunday 13 September 2015 06:17:04 Lisi Reisz wrote:
On Saturday 12 September 2015 23:28:46 Gene Heskett wrote:
The filter is primarily because in order for the current gs to print it, there needs to be a translation between a pdf and a ps.
Thanks, Gene. But my question was why?? Why does it have to be translated?
Lisi
GS, aka Ghostscript, back in v5 days, had a very good pdf level 2 renderer. It was also hell to compile, I did it twice on a big box amiga in the '90's.
Somewhere along the line, someone decided the best way to handle the bloat was to excise the pdf stuffs from ghostscript and let it concentrate on postscript only. Hence the need for a pipeing filter, called pdftops, to translate and expand the pdf into postscript that gs understands.
Both are random access file formats, but pdf uses a second lookup depth I haven't fully understood, and that must be translated and piped into gs as pure postscript.
FWIW, a properly done Level 3 pdf is the ultimate file compression when applied to a large document. This particular file that generates a 740 page, with lots of graphics, manual is just north of 121 megabytes. By the time pdftops has unpacked it and sent it to gs, it is still quite conmpressed, but the translation makes about 546 megabytes that gets sent over the pipe to gs. The resultant data that flows down the cat5 (or the slower USB if your printer doesn't have a network presence) to the printer is probably in excess of 5 terrabytes.
In the old days, I did not have a duplex capable printer, so I would command gs to make a file per page, then wrote an arexx script to send all odd pages to the printer, then when that was done, turn the pile over and then then send all the even numbered pages. But that filled up a 1Gb seagate drive , so had to be cleaned up if I wanted to do it to a different big pdf, else it was out of disk.
But I had to make the arexx script check the file size, and if it was under 100 bytes, it was nothing but the setup and teardown for the page, so rather than send that file to the printer, which if it was sitting at TOF, ignored a formfeed, so I sent it a line feed to get it off of TOF position, then the formfeed, which would eject the desired blank page, keeping the printout in the order desired, even for a 500+ page document. Without that, the binding ditch was fubar. Thats the space at the left edge of an odd page, or the right edge of an even page where a wider margin is used so the 3 hole punch misses the text.
I had an extended, and fruitless discussion with the gs maintainer at the time who couldn't conceive of a printer ignoring a formfeed if it was sitting at the top of the page already, but every Merican printer I ever had did ignore it including a couple Brother Daisy wheelers. Writing the arexx script was less hassle than trying to convince that person that he needed to add one linefeed byte in front of the formfeed. Sigh...
Your daily dose of ancient ghsotscript trivia. ;-)
Cheers Lisi, Gene Heskett
:-))
If the hard way will do, why use the easy way, eh, Gene. ;-) The harder and more abstruse the better. :-)
Lisi
Am Sonntag, 13. September 2015 schrieb Lisi Reisz:
Your daily dose of ancient ghsotscript trivia. ;-)
Cheers Lisi, Gene Heskett
:-))
If the hard way will do, why use the easy way, eh, Gene. ;-) The harder and more abstruse the better. :-)
Just ... why does that remind me of systemd?
Nik
On Sunday 13 September 2015 12:01:16 Lisi Reisz wrote:
On Sunday 13 September 2015 15:11:07 Gene Heskett wrote:
On Sunday 13 September 2015 06:17:04 Lisi Reisz wrote:
On Saturday 12 September 2015 23:28:46 Gene Heskett wrote:
The filter is primarily because in order for the current gs to print it, there needs to be a translation between a pdf and a ps.
Thanks, Gene. But my question was why?? Why does it have to be translated?
Lisi
GS, aka Ghostscript, back in v5 days, had a very good pdf level 2 renderer. It was also hell to compile, I did it twice on a big box amiga in the '90's.
Somewhere along the line, someone decided the best way to handle the bloat was to excise the pdf stuffs from ghostscript and let it concentrate on postscript only. Hence the need for a pipeing filter, called pdftops, to translate and expand the pdf into postscript that gs understands.
Both are random access file formats, but pdf uses a second lookup depth I haven't fully understood, and that must be translated and piped into gs as pure postscript.
FWIW, a properly done Level 3 pdf is the ultimate file compression when applied to a large document. This particular file that generates a 740 page, with lots of graphics, manual is just north of 121 megabytes. By the time pdftops has unpacked it and sent it to gs, it is still quite conmpressed, but the translation makes about 546 megabytes that gets sent over the pipe to gs. The resultant data that flows down the cat5 (or the slower USB if your printer doesn't have a network presence) to the printer is probably in excess of 5 terrabytes.
In the old days, I did not have a duplex capable printer, so I would command gs to make a file per page, then wrote an arexx script to send all odd pages to the printer, then when that was done, turn the pile over and then then send all the even numbered pages. But that filled up a 1Gb seagate drive , so had to be cleaned up if I wanted to do it to a different big pdf, else it was out of disk.
But I had to make the arexx script check the file size, and if it was under 100 bytes, it was nothing but the setup and teardown for the page, so rather than send that file to the printer, which if it was sitting at TOF, ignored a formfeed, so I sent it a line feed to get it off of TOF position, then the formfeed, which would eject the desired blank page, keeping the printout in the order desired, even for a 500+ page document. Without that, the binding ditch was fubar. Thats the space at the left edge of an odd page, or the right edge of an even page where a wider margin is used so the 3 hole punch misses the text.
I had an extended, and fruitless discussion with the gs maintainer at the time who couldn't conceive of a printer ignoring a formfeed if it was sitting at the top of the page already, but every Merican printer I ever had did ignore it including a couple Brother Daisy wheelers. Writing the arexx script was less hassle than trying to convince that person that he needed to add one linefeed byte in front of the formfeed. Sigh...
Your daily dose of ancient ghsotscript trivia. ;-)
Cheers Lisi, Gene Heskett
:-))
If the hard way will do, why use the easy way, eh, Gene. ;-) The harder and more abstruse the better. :-)
Lisi
My history at this computing thing goes back, way back. Software, except kpdf, has been fine tuned a bunch since those days 20 years ago.
kpdf was the culprit, it can't handle ALL variation of a png that have ever been generated. okular and evince both work.
Cheers, Gene Heskett
On Sunday 13 September 2015 20:15:06 Gene Heskett wrote:
My history at this computing thing goes back, way back.
So does that of most of us, but some of us use the modern way of doing things if it is quicker and easier.
I used to beat carpets on a washing line with a carpet beater. I use a vacuum cleaner now.
Lisi
-
Dr. Nikolaus Klepp -
Gene Heskett -
Greg Madden -
Kate Draven -
Lisi Reisz