Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Thomas Schmitt]

Hi,

Max Nikulin wrote:
> I admit "dithering" may be incorrect term, [...]
> Consider 2 squares having size of 2.5×2.5 pixels. Non-even sizes and fuzzy
> lines variants:
> █████
> ██████
> ████ ██
>██ ██
>█████
> Second variant might have sense if an image is treated as a photo unlikely
> having regular patterns with horizontal and vertical lines.

I see ...
The second rendering style is probably best described as "Bad Distortion".


Have a nice day :)

Thomas

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Max Nikulin]

On 20/03/2024 01:51, Thomas Schmitt wrote:

Max Nikulin wrote:

When vector graphics, that does not match device resolution, is rasterized,
the result is either non-even sizes of similar elements or fuzzy lines due
to dithering.


Nitpicking:

"Dithering" in raster graphics is emulation of color resolution at the
expense of space resolution.

[...]


The fuzzy lines are rather the opposite. They use surplus color
resolution to emulate ibetter spacial resolution. Over here the usual
term is "Anti-aliasing".


I admit "dithering" may be incorrect term, but I am in doubts if that 
printer (claimed to have 300dpi resolution, but not suitable for QR 
codes) has surplus color resolution. I do not mean anti-aliasing in the 
sense of adjusting pixels darkness (and color).


Consider 2 squares having size of 2.5×2.5 pixels. Non-even sizes and 
fuzzy lines variants:


█████
██████
████ ██
   ██ ██
   █████

Second variant might have sense if an image is treated as a photo 
unlikely having regular patterns with horizontal and vertical lines.

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Thomas Schmitt]

Hi,

Max Nikulin wrote:
> When vector graphics, that does not match device resolution, is rasterized,
> the result is either non-even sizes of similar elements or fuzzy lines due
> to dithering.

Nitpicking:

"Dithering" in raster graphics is emulation of color resolution at the
expense of space resolution. Multiple coarsly colored pixels together
create the impression of a finer color tone. A certain random aspect is
added to prevent unwanted patters.
  https://en.wikipedia.org/wiki/Dither

The fuzzy lines are rather the opposite. They use surplus color
resolution to emulate ibetter spacial resolution. Over here the usual
term is "Anti-aliasing".
  https://en.wikipedia.org/wiki/Line_drawing_algorithm
  https://www.geeksforgeeks.org/antialiasing/
I get a suspiciously high share of german language results when
searching this term in the web. But "Computer Grapics" by Foley, Van Dam,
Feiner, Hughes of 1990 has a dozen occurences in its Index.


Have a nice day :)

Thomas

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Max Nikulin]

On 13/03/2024 12:25, hw wrote:

On Mon, 2024-03-11 at 23:45 +0700, Max Nikulin wrote:

It seems you expect some number that you can use for any QR code. There
is no size that fits for all codes.


It's because you said: "I believed that 300dpi is high enough
resolution for QR-codes of reasonable size if source image has proper
quality." that I keep asking what you consider a reasonable size.


QR codes with more modules must be printed at larger size. Isn't it obvious?

By the way, is 300dpi real resolution of your printer or it is 
over-resolution achieved with overstrike with some offset? If so, does 
the printer driver take it into account?



Out of curiosity I tried to scan a QR code printed on a thermal printer
(so likely having ~200dpi resolution) having size of approximately 0.8in
and 50 pixels (modules) per inch. It encodes a 69 bytes long link.


Did you successfully scan it?


Instantly, no trouble at all.


It limits amount of information you may put into QR codes. You can still
choose to use e.g. 4,5,6, etc. printer dots per QR code module.


How can I choose that?  I don't know that there would be an option
with pdflatex or pdf or the printer driver that would let me choose
how many dots per module the printer puts onto the label.


When a code is generated you can look at it and count its modules. The 
next step is simple math. You have resolution, dots per module and 
number of modules, so you can get size and rerun LaTeX.



When I zoom in on QR-codes in a PDF viewer, they don't get blurry.
Perhaps the pst-barcode package uses vector graphics?


Nice, however you have to adjust size to avoid blurring.


How do you mean?  I thought vector graphics don't blur when scaled.


When vector graphics, that does not match device resolution, is 
rasterized, the result is either non-even sizes of similar elements or 
fuzzy lines due to dithering.


If a few multiplications and divisions is so hard problem and each QR 
code module occupy at least 3x3=9 printer dots then I would try to 
rotate the code by e.g. 30 or 45 degrees before printing.

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[jeremy ardley]

On 14/3/24 17:47, jeremy ardley wrote:
For reference on a 203 DPI (8 dots per mm) printer, a GS1-128 barcode 
takes up 12 modules per character. The minimum size of a module is 1 
pixel so 1 character is 12 pixels wide or 1.2mm on a 203 dpi printer.


Assuming a 40 character barcode at 1 pixel per module, it will span 48mm.

However it is very unusual to have 1 pixel per module. Instead at 2 
pixels per module the barcode is 96mm and at 3 pixels it will be 144mm



My error; The character spacing is 1.5mm at 203dpi. So 40 characters is 
60mm at 1 pixel per module, 120mm at 2 pixels per module, and 180mm at 3 
pixels per module. This means for a 40 character barcode you can at best 
print at 2 pixels per module on a typical 100x150m shipping label. This 
allows for no errors in quantization of pixel sizes and It's really hard 
to do with a printing system that does not start and continue with 
accurate pixel registration.

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[jeremy ardley]

On 14/3/24 06:59, hw wrote:

Manufacturers can provide CUPS drivers as well, but the barcode
application is usually only windows.

In my case I had to write my own CUPS driver as the manufacturer does
not provide one.

How did you do that?


It is simply a C program that gets given some parameters and a bitmap by 
CUPS


The program processes the bitmap and frames it with printer commands to 
place the bitmap on the printer page.


CUPS abstracts the actual device interface (in my case USB). But in 
development I wrote the code to send commands directly to the USB device





Getting back to pixel registration, the latex CUPS route is very
unlikely to work well.

It's working great here since years.  Barcodes are no problem, only qr
codes can't be scanned.



This surprises me greatly. 2D codes have very large features compared to 
barcodes. They should be relatively immune to pixel quantization.


For reference on a 203 DPI (8 dots per mm) printer, a GS1-128 barcode 
takes up 12 modules per character. The minimum size of a module is 1 
pixel so 1 character is 12 pixels wide or 1.2mm on a 203 dpi printer.


Assuming a 40 character barcode at 1 pixel per module, it will span 48mm.

However it is very unusual to have 1 pixel per module. Instead at 2 
pixels per module the barcode is 96mm and at 3 pixels it will be 144mm


With the barcode you have no leeway in the pixel sizes. You must have it 
exact to scan.


In comparison, a QR code typically will have modules 8 pixels square and 
typically is 26x26 or 32x32 pixels. At 26x26  the printed code is 26mm 
square at 203dpi. You can afford to be out by a pixel at those dimensions.


If you have problems scanning QR codes at those sizes perhaps your QR 
codes are invalid to start with? If you print them out really large will 
they scan?

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[hw]

On Wed, 2024-03-13 at 03:50 +0800, jeremy ardley wrote:
> On 12/3/24 21:21, hw wrote:
> > 
> > Even if they did that, it would be totally useless because it won't be
> > able to automatically print labels from databases.
> 
> The manufacturer applications  usually allow you to print a list from a 
> spreadsheet or text file.

That isn't very useful.

> > > It is possible to use document generation tools like latex and printing
> > > systems like CUPS to print a label, but pixel registration will be poor.
> > Why?  The manufacturer provided a CPUS printer driver without which
> > printing wouldn't be possible at all.
> 
> Most custom barcodes programs run on windows and don't use CUPS.

That makes them entirely useless.

> Manufacturers can provide CUPS drivers as well, but the barcode 
> application is usually only windows.
> 
> In my case I had to write my own CUPS driver as the manufacturer does 
> not provide one.

How did you do that?

> Getting back to pixel registration, the latex CUPS route is very 
> unlikely to work well.

It's working great here since years.  Barcodes are no problem, only qr
codes can't be scanned.



signature.asc
Description: This is a digitally signed message part

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Max Nikulin]

On 13/03/2024 02:50, jeremy ardley wrote:
Getting back to pixel registration, the latex CUPS route is very 
unlikely to work well.


TeX with MetaFont fonts worked well with low resolution dot matrix 
printers. Rasterized fonts may be generated for specified resolution. It 
should be still possible unless wide Unicode coverage is required.


I may be wrong, but I have impression that better support of modern 
vector fonts (TTF, OTF, etc.) in LuaTeX has other side. HurfBuz font 
library with priority to speed can not align characters to specified 
pixel grid. Likely nobody cares concerning font hints for low resolution 
devices.


Scale and position of images like QR codes should be adjusted to printer 
resolution.


More than a decade ago it was necessary to provide a document for 
archival purposes. I got a couple of complains: font with too thin lines 
and gray rather than black toner. The cartridge was refilled almost a 
dozen of times, but for routine documents quality was still good. 
CM-Super Type 1 font (converted from original Computer Modern with 
additions related to more scripts) really has hairlines. I configured 
metafont to increase minimal line width and generated a document with 
600dpi raster fonts using latex+dvips+ps2pdf instead of pdflatex. I went 
to a print shop nearby with hope to find there a printer filled with 
really black toner. The person there did not get the point why I was not 
satisfied looking into a test page from my document. It was blurry. 
Likely the page was scaled to printable area and dithering was applied. 
I preferred to go to another shop and got a stack of paper printed with 
proper quality. Either stuff there were a bit more experienced or 
default printer settings were more reasonable.


So it is not difficult to ruin efforts invested into print quality by 
inappropriate checkbox. The process is not fool-proof.

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Florent Rougon]

Florent Rougon  wrote:

>   - printer matrix alignment if printer resolution is low (more
> difficult; maybe try with some very small horizontal and veritical
> shifts to see if it helps...).

Thinking about it more, this is probably hopeless unless printer
resolution is *extremely* low. Typical printer dots are so small that
you can't realistically expect paper placement to have good enough
precision to align both grids (say, 1/4 of the printer dot size).

This is, I believe, what Jeremy meant when he wrote earlier in this
thread:

> Getting back to pixel registration, the latex CUPS route is very unlikely to
> work well. However a custom application that generates a pixel perfect bitmap
> that is printed at 100% scale through cups should work.

I agree with that if printer resolution is so low that the QR code and
printer dot grids have to be aligned. Even with perfect size in the PDF,
there is very little hope that paper will be every time correctly
aligned in the vertical and horizontal directions with the matrix of
dots managed by the printer—a dot at 300 dpi being approximately
0.08 mm. The only realistic hopes are:
  - high enough resolution that grid alignment doesn't really matter (is
300 dpi enough? Maybe.);
  - direct control over the printer bitmap (what Jeremy mentioned).

For the sake of completeness, the following LaTeX document (an inline
attachment) draws a QR code whose modules are correctly placed for some
“ideal” 300 dpi printer. This assumes that printer dots perfectly start
at a dot-size multiple from the top left corner of the physical page,
which probably can't be obtained in practice. So, this is mainly to show
how accurate placement and computations can be done (\fpeval is provided
by xfp; it is very accurate and expandable).

\documentclass{article}
\usepackage[papersize={50mm,35mm},margin=0cm]{geometry}
\usepackage{xfp}
\usepackage{qrcode}

\pagestyle{empty}
\newlength{\modulesize}
\setlength{\modulesize}{\fpeval{6/300}in}% assume 300 dpi, set 6 dots/module

\begin{document}

\noindent
\hspace{10\modulesize}% horizontal offset from paper edge: 10 modules
\raisebox{\dimexpr \topskip - \height - 10\modulesize}{% ditto in vert. direction
  \qrcode[height=25\modulesize, version=2]{Hey Debian-user!}}%
% The modules will have the expected size only if the QR code is effectively
% doable at version=2 (check the LaTeX terminal output). Indeed, version=2
% means 25×25 modules.

\end{document}

Regards

-- 
Florent

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Florent Rougon]

hw  wrote:

>> That is quite likely: the pst- prefix means this is PSTricks, which is
>> an oldish way of doing vector graphics with LaTeX. I tend to avoid
>> PSTricks these days as it is generally awkward to use in PDF contexts,
>> although there are various workarounds that often allow to do so.
>
> Is that bad?  It works great for what I'm doing.

Well, “bad” is a strong word in this context. ;-) First, PDF has been
replacing PostScript in the last 20+ years, so it is often easier to
find tools that do interesting things with PDF than with PostScript.

Second, regarding the existing workarounds that allow PSTricks code to
be used in PDF workflows: I haven't used many of them but AFAIK, most of
the times, if you want things to work automatically, you need to enable
\write18 which has security implications. In the most relaxed case, it
allows the compiled document, as well as any class or package it loads,
to run arbitrary shell commands. There is a restricted mode for \write18
(see -shell-restricted and “§5.5 Shell escapes” in `texdoc web2c`), but
it currently doesn't allow running ps2pdf:

,[ /usr/share/texmf/web2c/texmf.cnf ]
| shell_escape_commands = \
| bibtex,bibtex8,\
| extractbb,\
| gregorio,\
| kpsewhich,\
| makeindex,\
| memoize-extract.pl,\
| memoize-extract.py,\
| repstopdf,\
| r-mpost,\
| texosquery-jre8,\
| 
| % we'd like to allow:
| % dvips - but external commands can be executed, need at least -R1.
| % epspdf, ps2pdf, pstopdf - need to respect openout_any,
| %   and gs -dSAFER must be used and check for shell injection with filenames.
| ...
`

One of the problems with PostScript is that it is “too powerful” for
something that should only produce text and graphics—AIUI, security
concerns were not at the core of its design.

Finally, for a few things like transparency and “new” font formats
(e.g., TrueType, OpenType), PostScript is either a no-go or has
solutions that appeared very late, contrary to PDF.

>> The ubiquitous, powerful and modern way to do vector graphics in LaTeX
>> is PGF/TiKZ[1],
>
> That package has almost 1300 pages of documentation which doesn't seem
> to mention qr-codes or barcodes.

Right. Presumably, the qrcode package is good enough. BTW, since its
\qrcode command produces a TeX box without using any TikZ code, it can
be placed without restriction in a TikZ node (I say this because TikZ
nodes can't be nested—more precisely, doing so is not supported).

> I wonder why it uses different options for URLs and other data.  What
> difference does that make?

I believe you misunderstood the manual here, or maybe I don't understand
what you meant. The \qrcode command can encode both URLs and other text.
What I see is simply options (and the starred variant \qrcode*) to
decide whether to turn the QR codes into PDF hyperlinks.

Global switch at \usepackage level:  hyperlinks/nolinks
Local switch for each \qrcode command:   link/nolink

\qrcode*{…} == \qrcode[nolink]{…}

These options are provided because when the hyperref package is loaded,
QR codes are output as hyperlinks by default; however, it is quite
possible to write QR codes that don't encode URLs, in which case making
them hyperlinks would be confusing and useless.

> It might be worth a try for when I need to experiment with qr-codes on
> small labels again.  It might not work because I may need to place the
> qr-code in some way and it could conflict with other packages like the
> labels package ...  I even might have already tried it; it's been a
> few years and I don't remember exactly.

Since \qrcode outputs a TeX box without using any TikZ code, it has
about the highest level of “compatibility” you can expect in a TeX
document.

> Now I'm wondering why the qr-codes I printed with the label printer
> couldn't be reliably scanned.  When I look at [1] and [2], for the
> data I wanted to print (between 38 and 40 alphanumericals at L
> quality) I would have to use a version 2 qr code, i. e. 25x25 modules.
> I don't know how the modules transfer to dots, but assuming the
> minimum of 4 dots per module, it would take 25 x 4 dots, i. e. 100
> dots.  Each module would be 0.33mm in size which would require 25 x
> 0.33mm, i. e. 8.25mm for the size of the qr-code.
>
> I printed the qr-code much larger than that, about 1x1".  That is
> about three times as large as would be required, and the printer can
> print three times as many dots per inch as the 100 dots needed.
>
> So in theory, my theory that the resolution of the printer is too low
> can't be true.
>
> But why couldn't these qr-codes be scanned?  It shouldn't have been a
> problem at all.

L quality is the worst; can't you use a better one? Also worth
considering:

  - scanner limitation? Did you try to scan the codes with a smartphone?

  - printer matrix alignment if printer resolution is low (more
difficult; maybe try with some very small horizontal and veritical
shifts to see if it helps...).

Regards

-- 
Florent

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[hw]

On Mon, 2024-03-11 at 23:45 +0700, Max Nikulin wrote:
> On 11/03/2024 08:06, hw wrote:
> > On Sun, 2024-03-10 at 09:50 +0700, Max Nikulin wrote:
> > > On 10/03/2024 04:41, hw wrote:
> > > > \psbarcode{textblah foo}{height=0.6 width=0.6 eclevel=L}{qrcode}
> > > > 
> > > > That works for 600dpi laser printers.  When you print the QR-code with
> > > > a 300dpi label printer you can't reliably scan it, not even when you
> > > > make the QR-code 1x1" in size.
> > > > 
> > > > Perhaps that's not a reasonable size?
> > > 
> > > Perhaps height and width are chosen improperly. An image some percents
> > > smaller may be sharper.
> > 
> > What size do you consider reasonable?
> 
> It seems you expect some number that you can use for any QR code. There 
> is no size that fits for all codes.

It's because you said: "I believed that 300dpi is high enough
resolution for QR-codes of reasonable size if source image has proper
quality." that I keep asking what you consider a reasonable size.

> Out of curiosity I tried to scan a QR code printed on a thermal printer 
> (so likely having ~200dpi resolution) having size of approximately 0.8in 
> and 50 pixels (modules) per inch. It encodes a 69 bytes long link. 
> Likely the same code scaled to 0.4in will still work, but I would prefer 
> to avoid it, 0.6in should be more reliable. On your 300dpi printer this 
> particular QR code may be printed e.g. at ~(0.8/1.5)in.

Did you successfully scan it?

> > [...]
> > The QR-code must fit on the label, plus some text.  The labels are
> > 50x35mm in size.
> 
> It limits amount of information you may put into QR codes. You can still 
> choose to use e.g. 4,5,6, etc. printer dots per QR code module.

How can I choose that?  I don't know that there would be an option
with pdflatex or pdf or the printer driver that would let me choose
how many dots per module the printer puts onto the label.

> > When I zoom in on QR-codes in a PDF viewer, they don't get blurry.
> > Perhaps the pst-barcode package uses vector graphics?
> 
> Nice, however you have to adjust size to avoid blurring.

How do you mean?  I thought vector graphics don't blur when scaled.



signature.asc
Description: This is a digitally signed message part

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[hw]

On Mon, 2024-03-11 at 11:58 +0100, Florent Rougon wrote:
> Hi,
> 
> I haven't read the whole thread (sorry) but thought this might help.
> 
> hw  wrote:
> 
> > When I zoom in on QR-codes in a PDF viewer, they don't get blurry.
> > Perhaps the pst-barcode package uses vector graphics?
> 
> That is quite likely: the pst- prefix means this is PSTricks, which is
> an oldish way of doing vector graphics with LaTeX. I tend to avoid
> PSTricks these days as it is generally awkward to use in PDF contexts,
> although there are various workarounds that often allow to do so.

Is that bad?  It works great for what I'm doing.

> The ubiquitous, powerful and modern way to do vector graphics in LaTeX
> is PGF/TiKZ[1],

That package has almost 1300 pages of documentation which doesn't seem
to mention qr-codes or barcodes.

> however this is not even necessary for QR codes, because
> [...]

good :)

> I've played with a different package for producing QR codes in LaTeX,
> which uses the aforementioned \hrule and \vrule primitives: qrcode. Its
> manual is here (follow the “Package documentation” link):
> 
>   https://ctan.org/pkg/qrcode

I wonder why it uses different options for URLs and other data.  What
difference does that make?

> Here is a simple example you can compile with pdflatex:
> 
> \documentclass{article}
> \usepackage{qrcode}
> 
> \pagestyle{empty}
> 
> \begin{document}
> 
> \noindent
> % \qrset affects \qrcode commands in the current group. You can use it
> % to factor out options used for several QR codes.
> \qrset{nolinks, padding}% add padding to make sure the codes are 
> “legal”/readable
> \qrcode[version=1]{Hey Debian-user!}% Can't do version=1 with level=M or more
> \qrcode[level=L, version=1]{Hey Debian-user!}% Less redundancy but is doable
> 
> \end{document}
> 
> Note the terminal output:
> 
> 
> 
>  Version increased to '2' to fit text.>
> 
> 
>  calculated.>
> 
> 
> 
> 
>  calculated.>
> 

It might be worth a try for when I need to experiment with qr-codes on
small labels again.  It might not work because I may need to place the
qr-code in some way and it could conflict with other packages like the
labels package ...  I even might have already tried it; it's been a
few years and I don't remember exactly.

> [...]
> But with low printer resolution constraints, who knows?).
> 
> Hope this helps!

Yes, thanks, knowing about these packages can be useful.

Now I'm wondering why the qr-codes I printed with the label printer
couldn't be reliably scanned.  When I look at [1] and [2], for the
data I wanted to print (between 38 and 40 alphanumericals at L
quality) I would have to use a version 2 qr code, i. e. 25x25 modules.
I don't know how the modules transfer to dots, but assuming the
minimum of 4 dots per module, it would take 25 x 4 dots, i. e. 100
dots.  Each module would be 0.33mm in size which would require 25 x
0.33mm, i. e. 8.25mm for the size of the qr-code.

I printed the qr-code much larger than that, about 1x1".  That is
about three times as large as would be required, and the printer can
print three times as many dots per inch as the 100 dots needed.

So in theory, my theory that the resolution of the printer is too low
can't be true.

But why couldn't these qr-codes be scanned?  It shouldn't have been a
problem at all.


[1]: https://www.qrcode.com/en/about/version.html
[2]: https://www.qrcode.com/en/howto/cell.html

> 
> Regards
> 
> [1] https://ctan.org/pkg/pgf
> 





signature.asc
Description: This is a digitally signed message part

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[jeremy ardley]

On 12/3/24 21:21, hw wrote:


Even if they did that, it would be totally useless because it won't be
able to automatically print labels from databases.


The manufacturer applications  usually allow you to print a list from a 
spreadsheet or text file.



It is possible to use document generation tools like latex and printing
systems like CUPS to print a label, but pixel registration will be poor.

Why?  The manufacturer provided a CPUS printer driver without which
printing wouldn't be possible at all.


Most custom barcodes programs run on windows and don't use CUPS.

Manufacturers can provide CUPS drivers as well, but the barcode 
application is usually only windows.


In my case I had to write my own CUPS driver as the manufacturer does 
not provide one.


Getting back to pixel registration, the latex CUPS route is very 
unlikely to work well. However a custom application that generates a 
pixel perfect bitmap that is printed at 100% scale through cups should work.


There are a number of programs that can do that, though I have not used 
them so far.


- zint

- GNU barcode

- BWIPP

also a possibility is

- qrencode

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[hw]

On Mon, 2024-03-11 at 09:57 +0800, jeremy ardley wrote:
> On 11/3/24 07:34, hw wrote:
> > Do you think that thermal transfer printers with 203dpi would be
> > better suited to print QR codes than the 300dpi multi-mode printers?
> > 
> > I'm not fond of thermal transfer at all.  Usually what is being
> > printed that way fades rather quickly over time and is more slightly
> > gray rather than black and so thin that it's hard to read even when
> > freshly printed.  Perhaps better labels are available, but the labels
> > must not get too expensive ...
> 
> 
> Thermal transfer and thermal direct printers have the same resolution.
> 
> Thermal transfer printers are used for archival labels as they fade very 
> little over time.
> 
> Direct thermal printers are intended for mailing applications where it 
> doesn't matter if they fade after a few months.
> 
> Given that, I think a lot of commercial shippers use thermal transfer 
> for mailing labels. Very few shippers use laser printed adhesive address 
> label, nor non-adhesive in pockets or pouches.
> 
> To print a QR code or other 2D code on any thermal printer, the printer 
> manufacturer will supply an application that generate the codes and 
> prints them independently of the host printing system. These codes will 
> scan perfectly.

Even if they did that, it would be totally useless because it won't be
able to automatically print labels from databases.

> It is possible to use document generation tools like latex and printing 
> systems like CUPS to print a label, but pixel registration will be poor. 

Why?  The manufacturer provided a CPUS printer driver without which
printing wouldn't be possible at all.

> The only practical option for this route is to print the code BIG
 
That's what I thought, but then the codes won't fit on the labels.
That's why I wonder if there's a better way.



signature.asc
Description: This is a digitally signed message part

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Max Nikulin]

On 11/03/2024 08:06, hw wrote:

On Sun, 2024-03-10 at 09:50 +0700, Max Nikulin wrote:

On 10/03/2024 04:41, hw wrote:

\psbarcode{textblah foo}{height=0.6 width=0.6 eclevel=L}{qrcode}

That works for 600dpi laser printers.  When you print the QR-code with
a 300dpi label printer you can't reliably scan it, not even when you
make the QR-code 1x1" in size.

Perhaps that's not a reasonable size?


Perhaps height and width are chosen improperly. An image some percents
smaller may be sharper.


What size do you consider reasonable?


It seems you expect some number that you can use for any QR code. There 
is no size that fits for all codes.


Out of curiosity I tried to scan a QR code printed on a thermal printer 
(so likely having ~200dpi resolution) having size of approximately 0.8in 
and 50 pixels (modules) per inch. It encodes a 69 bytes long link. 
Likely the same code scaled to 0.4in will still work, but I would prefer 
to avoid it, 0.6in should be more reliable. On your 300dpi printer this 
particular QR code may be printed e.g. at ~(0.8/1.5)in.


Fix size of QR code pixel (module), not size of whole QR code.


- Find number of pixels in QR code in QR specs (or just calculate them)


Calculate them how or find them where?  Pdflatex somehow does it and
the QR-codes are fine when printed on a laser printer and when shown
on a 4k display.


"Modules" in Florent's message is what I referred to as QR code "pixels" 
and their count depends on "version".



- Specify width and height so that the ration of 2 numbers above is a
whole number.

Image may become a bit larger or a bit smaller.


The QR-code must fit on the label, plus some text.  The labels are
50x35mm in size.


It limits amount of information you may put into QR codes. You can still 
choose to use e.g. 4,5,6, etc. printer dots per QR code module.



When I zoom in on QR-codes in a PDF viewer, they don't get blurry.
Perhaps the pst-barcode package uses vector graphics?


Nice, however you have to adjust size to avoid blurring.

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Florent Rougon]

Hi,

I haven't read the whole thread (sorry) but thought this might help.

hw  wrote:

> When I zoom in on QR-codes in a PDF viewer, they don't get blurry.
> Perhaps the pst-barcode package uses vector graphics?

That is quite likely: the pst- prefix means this is PSTricks, which is
an oldish way of doing vector graphics with LaTeX. I tend to avoid
PSTricks these days as it is generally awkward to use in PDF contexts,
although there are various workarounds that often allow to do so.

The ubiquitous, powerful and modern way to do vector graphics in LaTeX
is PGF/TiKZ[1], however this is not even necessary for QR codes, because
these are made of perfect monochrome rectangles, which TeX can draw
natively using its \hrule and \vrule primitives.

> 'pdfimages -list' doesn't show any images for a PDF with QR-codes
> created with pdflatex.

AFAIK, 'pdfimages' would extract “actual images” embedded in a PDF file
(e.g., PNG or JPG), however here pst-barcode presumably uses PostScript
or PDF primitives for drawing and filling polygons, which in your case
probably end up as PDF primitives. Hence, 'pdfimages' can't see these QR
codes (AFAIUI).

I've played with a different package for producing QR codes in LaTeX,
which uses the aforementioned \hrule and \vrule primitives: qrcode. Its
manual is here (follow the “Package documentation” link):

  https://ctan.org/pkg/qrcode

Here is a simple example you can compile with pdflatex:

\documentclass{article}
\usepackage{qrcode}

\pagestyle{empty}

\begin{document}

\noindent
% \qrset affects \qrcode commands in the current group. You can use it
% to factor out options used for several QR codes.
\qrset{nolinks, padding}% add padding to make sure the codes are 
“legal”/readable
\qrcode[version=1]{Hey Debian-user!}% Can't do version=1 with level=M or more
\qrcode[level=L, version=1]{Hey Debian-user!}% Less redundancy but is doable

\end{document}

Note the terminal output:














There are several quality levels allowing error correction (see the
manual): Low, Medium, Quality, and High. They correspond to 'level'
values L, M, Q, H. Default is M but if the chosen 'version' (which maps
to a specific number of modules) allows for a better level, qrcode
automatically upgrades to the best level possible for the chosen
'version' (which the above log demonstrates for the first QR code).

My example tries to print two QR codes with version=1, which means
21×21 modules (see below). Using the default level (M), this is not
possible for the specified text, therefore the first QR code is drawn as
a version=2 one (i.e., it has 25×25 modules). For the second QR code, I
explicitly ask for level=L which has the worst redundancy for error
correction; this allows "Hey Debian-user!" to be QR-encoded with
version=1, i.e. as a square of 21×21 modules.

The length of what you are encoding obviously dictates which quality
parameters you can afford, so you need to play with actual text for your
application. You can control the size of the QR code with e.g.
\qrcode[height=1cm]{...}. Since the modules are stuck to each other,
once you've determined an appropriate 'version' parameter, you can
easily choose a height that causes the modules to have the exact size
you want in the resulting PDF file (printer driver issues are out of my
league).

Regarding the 'version' parameter:

  version=1  → 21×21 modules
  version=2  → 25×25 modules
  version=3  → 29×29 modules
  ...
  version=40 → 177×177 modules

(each version step adds 4 to the number of modules in each direction)

So, you may want to play with text of yours and these parameters.
Examine the terminal output or log file to make sure the qrcode package
didn't have to increase the 'version' in order to encode the text you
specified. Note that in my example, the second QR code scanned with a
smartphone from a computer screen display seems to be significantly
harder to recognize than the first one (IOW, using level=L is probably a
bad idea even though it allows one to reduce the number of modules. But
with low printer resolution constraints, who knows?).

Hope this helps!

Regards

[1] https://ctan.org/pkg/pgf

-- 
Florent

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[jeremy ardley]

On 11/3/24 07:34, hw wrote:

Do you think that thermal transfer printers with 203dpi would be
better suited to print QR codes than the 300dpi multi-mode printers?

I'm not fond of thermal transfer at all.  Usually what is being
printed that way fades rather quickly over time and is more slightly
gray rather than black and so thin that it's hard to read even when
freshly printed.  Perhaps better labels are available, but the labels
must not get too expensive ...



Thermal transfer and thermal direct printers have the same resolution.

Thermal transfer printers are used for archival labels as they fade very 
little over time.


Direct thermal printers are intended for mailing applications where it 
doesn't matter if they fade after a few months.


Given that, I think a lot of commercial shippers use thermal transfer 
for mailing labels. Very few shippers use laser printed adhesive address 
label, nor non-adhesive in pockets or pouches.


To print a QR code or other 2D code on any thermal printer, the printer 
manufacturer will supply an application that generate the codes and 
prints them independently of the host printing system. These codes will 
scan perfectly.


It is possible to use document generation tools like latex and printing 
systems like CUPS to print a label, but pixel registration will be poor. 
The only practical option for this route is to print the code BIG

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[hw]

On Sun, 2024-03-10 at 09:50 +0700, Max Nikulin wrote:
> On 10/03/2024 04:41, hw wrote:
> > \psbarcode{textblah foo}{height=0.6 width=0.6 eclevel=L}{qrcode}
> > 
> > That works for 600dpi laser printers.  When you print the QR-code with
> > a 300dpi label printer you can't reliably scan it, not even when you
> > make the QR-code 1x1" in size.
> > 
> > Perhaps that's not a reasonable size?
> 
> Perhaps height and width are chosen improperly. An image some percents 
> smaller may be sharper.

What size do you consider reasonable?

> - Find the dpi value in the specs of your printer

300dpi

> - Find number of pixels in QR code in QR specs (or just calculate them)

Calculate them how or find them where?  Pdflatex somehow does it and
the QR-codes are fine when printed on a laser printer and when shown
on a 4k display.

> - Specify width and height so that the ration of 2 numbers above is a 
> whole number.
> 
> Image may become a bit larger or a bit smaller.

The QR-code must fit on the label, plus some text.  The labels are
50x35mm in size.

That limits the QR-code to about 1x1", give or take a few mm.  1" is
already half the width of the label which doesn't leave much room for
text, and you have to give it some slack because you want to end up
printing somewhere on the label and not on the gaps between the
labels.

When I zoom in on QR-codes in a PDF viewer, they don't get blurry.
Perhaps the pst-barcode package uses vector graphics?

'pdfimages -list' doesn't show any images for a PDF with QR-codes
created with pdflatex.



signature.asc
Description: This is a digitally signed message part

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[hw]

On Sun, 2024-03-10 at 07:56 +0800, jeremy ardley wrote:
> On 10/3/24 05:41, hw wrote:
> > The QR-codes are sharp and easily scanable when printed in 600dpi.
> > With the label printer you can't really tell if they're sharp or not.
> 
> As  mentioned in my previous post, thermal label printers are 203dpi, 
> *not the 300 that the OP quoted.*

The printers I've been printing on are 300dpi and can do both thermal
and ribbon/ink.  I haven't tried thermal.

> [...]
> The data_matrix code (like a QRcode) for the same 41 digits is a 26x26 matrix 
> which at 203dpi can have pixels of 8x8 dots in a field of 26x26mm. These are 
> super easy for a thermal printer

Do you think that thermal transfer printers with 203dpi would be
better suited to print QR codes than the 300dpi multi-mode printers?

I'm not fond of thermal transfer at all.  Usually what is being
printed that way fades rather quickly over time and is more slightly
gray rather than black and so thin that it's hard to read even when
freshly printed.  Perhaps better labels are available, but the labels
must not get too expensive ...



signature.asc
Description: This is a digitally signed message part

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[hw]

On Sun, 2024-03-10 at 10:21 +0700, Max Nikulin wrote:
> On 10/03/2024 03:48, jeremy ardley wrote:
> > 
> > Standard thermal label printers are 203DPI (8 dots per mm).
> 
> Thanks, this number suits better to my expectation. I just trusted hw 
> earlier.

I should clarify:

The printer the OP pointed to seems to be rated at 203DPI and I
somehow thought it had 300dpi.  (203 seems very odd.)

The printers I have been trying to print QR-codes on are actually
300dpi printers.  They can do both thermal transfer or use a ribbon
that transfers ink to the labels kinda like typewriters did.  I
haven't used the thermal transfer mode and only the ribbon/ink mode.

> > I have asked the postal service to generate labels at 203dpi which will 
> > print just fine at 600 dpi and so work with laser and thermal printers, 
> > but they will not cooperate.

Why would they create labels that can not be scanned when printed?

Maybe ask them to print the labels for you?  If they can't scan them
then that's their problem.



signature.asc
Description: This is a digitally signed message part

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[jeremy ardley]

On 10/3/24 15:39, Max Nikulin wrote:
From your earlier message I count approximately 1000px for 5in (125 
mm) barcode. If it is 1:1 to ~200dpi then it is incompatible with 
300dpi printers, so it may be a reason why your proposal to the post 
office was rejected. If it is 500 black or white lines and each one 
occupies 2 printer dots then 300dpi image of the same size has 3 dots 
per line. (Sorry, I am unsure concerning "module" term.) You should be 
able to rasterize PDF files to 600dpi (2x factor) and downsample them 
by 1/3 keeping lines sharp.


In barcodes such as Code-128 a module is 12 'slots' which at minimum is 
one pixel per slot or 12 pixels. Code-128 has over 100 character 
encodings in a module.


So code 128 on a 203dpi printer 12 * characters / 8 mm e.g. for 40 
characters it's 12*40/8 = 60mm. 2 pixels per module make it 120mm. 3 
pixels per module make it 180mm so too big for mailing labels.


As for my post office, their barcodes do not match 300dpi or 600dpi. 
They are scaled at about 75-80% of what they should be. I'm really 
surprised they work. I can only guess most people use 1200dpi.


Thermal labels are the way to go as they stick really well and resist 
water. They are also *cheap*. around 1-2 cents in bulk for 100x150 . 
Plastic envelope and laser printed label will cost 10-20c. A self 
adhesive laser label is getting on to 50c.

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Max Nikulin]

On 10/03/2024 10:51, jeremy ardley wrote:


I have far less problems with the QR code (in my case data_matrix code) 
than with the barcode. The pixel elements of the QR code are much larger 
than the lines in a barcode so there is much less chance for pixel 
ambiguity.


From your earlier message I count approximately 1000px for 5in (125 mm) 
barcode. If it is 1:1 to ~200dpi then it is incompatible with 300dpi 
printers, so it may be a reason why your proposal to the post office was 
rejected. If it is 500 black or white lines and each one occupies 2 
printer dots then 300dpi image of the same size has 3 dots per line. 
(Sorry, I am unsure concerning "module" term.) You should be able to 
rasterize PDF files to 600dpi (2x factor) and downsample them by 1/3 
keeping lines sharp.


Certainly this simple trick would fail if QR in the same file requires 
3/4 scaling.



from pdf2image import convert_from_path


The pdfimage(1) tool may extract images in their original format, 
perhaps there is a similar python module.



     detected_codes = pyzbar.decode(img)


Each barcode and QR code may be resampled individually without 
recognizing it. If position of each image on the page is known,
resampled images may be put back to correct places in the document 
rasterized to your printer resolution.


P.S. Post office guys may believe that labels created using laser 
printers are more resistant to wearing during processing and delivery, 
so 300dpi resolution may be intentional to discourage usage of thermal 
printers.

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[jeremy ardley]

On 10/3/24 11:21, Max Nikulin wrote:


Is the QR image a raster one? I am unsure concerning its printer dots 
per QR pixel ratio. Let's take e.g. 4 as a value inconvenient for 
direct scaling from 300dpi to 203dpi. I expect that upscaling it by 3 
and downscaling the result by 4 with disabled smoothing (e.g. using 
splines) should generate an image that is 1.5% larger than the one 
suitable for 203dpi. So setting 98.5% scaling for printer should allow 
to achieve sharp QR image without re-encoding QR.



In my case I have never seen a bigger dogs breakfast of a pdf! It has 
many elements in different formats including bitmaps, scalable vector 
graphics, and text elements. That and some images are colour and some 
black and white. I just preprocess it


I have far less problems with the QR code (in my case data_matrix code) 
than with the barcode. The pixel elements of the QR code are much larger 
than the lines in a barcode so there is much less chance for pixel 
ambiguity.


I think i you make it 'big enough' it will scan fine. So a factor of 2 
magnification should work with a QR code.


I spent many (un)happy hours with gimp and imagemagick to try and get 
the best solution for barcodes. Sadly there is none other than print the 
barcode as big as possible in your page real-estate.


I spent an hour today with my friend GPT4 and python and I can now pluck 
out any and all codes from my mailing labels and I next plan to generate 
new labels at 203dpi using freshly encoded barcodes and data_matrix codes.


Here is some experimental code

from PIL import Image
import pyzbar.pyzbar as pyzbar
import qrcode  # For generating QR codes
from barcode import EAN13, generate  # Using EAN13 as an example; this 
might vary

from barcode.writer import ImageWriter
import os

from pdf2image import convert_from_path

def pdf_to_image(pdf_path, dpi=600):
    images = convert_from_path(pdf_path, dpi=dpi)
    for img in images:
    yield img

def detect_and_extract_codes(images):
    for img in images:
    detected_codes = pyzbar.decode(img)
    for code in detected_codes:
    print(code)
    if code.type == 'QRCODE':
    # Process QR code
    process_qr_code(code)
    else:
    # Process other types of barcodes
    process_barcode(code)

def process_qr_code(code):
    qr = qrcode.QRCode(
    version=1,
    error_correction=qrcode.constants.ERROR_CORRECT_L,
    box_size=10,
    border=4,
    )
    qr.add_data(code.data.decode())
    qr.make(fit=True)
    img = qr.make_image(fill_color="black", back_color="white")
    img.show()  # Or save the image

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Max Nikulin]

On 10/03/2024 03:48, jeremy ardley wrote:


Standard thermal label printers are 203DPI (8 dots per mm).


Thanks, this number suits better to my expectation. I just trusted hw 
earlier.


I have asked the postal service to generate labels at 203dpi which will 
print just fine at 600 dpi and so work with laser and thermal printers, 
but they will not cooperate.


Is the QR image a raster one? I am unsure concerning its printer dots 
per QR pixel ratio. Let's take e.g. 4 as a value inconvenient for direct 
scaling from 300dpi to 203dpi. I expect that upscaling it by 3 and 
downscaling the result by 4 with disabled smoothing (e.g. using splines) 
should generate an image that is 1.5% larger than the one suitable for 
203dpi. So setting 98.5% scaling for printer should allow to achieve 
sharp QR image without re-encoding QR.


You may try to find rational approximation for (4*208)/300 better than 
4/3 (or for actual QR pixel size).

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Max Nikulin]

On 10/03/2024 04:41, hw wrote:

\psbarcode{textblah foo}{height=0.6 width=0.6 eclevel=L}{qrcode}

That works for 600dpi laser printers.  When you print the QR-code with
a 300dpi label printer you can't reliably scan it, not even when you
make the QR-code 1x1" in size.

Perhaps that's not a reasonable size?


Perhaps height and width are chosen improperly. An image some percents 
smaller may be sharper.


- Find the dpi value in the specs of your printer
- Find number of pixels in QR code in QR specs (or just calculate them)
- Specify width and height so that the ration of 2 numbers above is a 
whole number.


Image may become a bit larger or a bit smaller.

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[jeremy ardley]

On 10/3/24 05:41, hw wrote:

The QR-codes are sharp and easily scanable when printed in 600dpi.
With the label printer you can't really tell if they're sharp or not.


As  mentioned in my previous post, thermal label printers are 203dpi, 
*not the 300 that the OP quoted.*


you can read the OP specs here which say 203. 
.


Thermal label printers have no problems printing even long bar codes, QR codes, 
and data_matrix codes if the generator uses the correct dpi and the print 
process maintains the pixel mapping.

In my case my barcodes are 41 digits long (extreme GS1 !) and at 2 pixels per 
module (12 modules per digit) it is 123mm long which fits into a 150x100 
thermal label

The data_matrix code (like a QRcode) for the same 41 digits is a 26x26 matrix 
which at 203dpi can have pixels of 8x8 dots in a field of 26x26mm. These are 
super easy for a thermal printer

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[hw]

On Sat, 2024-03-09 at 23:20 +0700, Max Nikulin wrote:
> On 09/03/2024 19:08, hw wrote:
> > On Fri, 2024-03-08 at 23:21 +0700, Max Nikulin wrote:
> > > On 08/03/2024 12:35, hw wrote:
> > > > On Thu, 2024-03-07 at 23:15 -0500, Jeffrey Walton wrote:
> > > > > 
> > > > > I have a USB thermal printer for the shipping labels,
> > > > > .
> > > > 
> > > > This printer has only 300dpi.  If you print QR-codes on it make sure
> > > > you can scan them: they have to be large enough or get you an
> > > > unscanable smear.
> > > 
> > > I believed that 300dpi is high enough resolution for QR-codes of
> > > reasonable size if source image has proper quality. On the other hand,
> > > if possible, it is better to scale QR-codes to match some whole factor
> > > of printer pixel size.
> > 
> > What do you consider a 'reasonable size'?
> 
> Looking at a QR code likely having ~75 pixels per inch I find it 
> unreasonably small for delivery labels.

Shipping labels tend to be pretty large.

> I am in doubts if its redundancy is high enough to reliably
> recognize it if it would be scratched during delivery. Another

Increased redundancy can make the QR-code harder or impossible to
scan because it creates more smear instead of more redundancy.

Once you've seen what that looks like, it is evident that smearing
more ink into the same area for more redundancy makes things only
worse.  You'd have to print the QR-code larger.

> limitation may be stability of optics in scanners in respect to
> labels. This one is printed using a laser printer with resolution at
> least 600 dpi. Each QR code pixel has still 4x4 printer dots in the
> case of 300dpi, so when image is properly aligned, printer quality
> is not an issue.

Yes, the QR-codes printed on a 600dpi laser printer are fine.

> > There is no source image other than whatever LaTeX creates.  I can
> > specify the size of the QR-code.  Other than that, how do you apply
> > scaling?
> 
> I am unsure what particular QR code generator do you use and what is the 

I'm using the pst-barcode package and pdflatex to create a PDF file
which is then sent through cups to the printer.  So LaTeX, the
bst-barcode package, some PDF stuff, the printer driver, the printer
and it's settings for darkness and printing speed, the material the
labels are made of and the ribbon with the ink on it which gets
transferred to the label all influence the result.

Also, labels are continuously being fed through the printer while
printing without stopping.  That makes some smear inevitable.

> format of QR codes.

It basically goes like this:

\psbarcode{textblah foo}{height=0.6 width=0.6 eclevel=L}{qrcode}

That works for 600dpi laser printers.  When you print the QR-code with
a 300dpi label printer you can't reliably scan it, not even when you
make the QR-code 1x1" in size.

Perhaps that's not a reasonable size?

> Is it raster or vector image? Specify size that makes QR code pixels
> having whole number of printer pixels.

I only know that the QR-code must fit on the label.

> "Fit to page" or "fit to printable area" in printer options may make an 
> image blurry.

No such options are specified.

> In the case of low input image resolution, upscaling method suitable
> for photos may make QR code blurry. However consistent configuration
> should make QR codes sharp.

IIRC there is an option to create a PDF having a particular
resolution, like 300DPI, but that didn't seem to have any effect.  I
don't remember what that option was :/

The QR-codes are sharp and easily scanable when printed in 600dpi.
With the label printer you can't really tell if they're sharp or not.




signature.asc
Description: This is a digitally signed message part

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[jeremy ardley]

On 10/3/24 00:20, Max Nikulin wrote:


Looking at a QR code likely having ~75 pixels per inch I find it 
unreasonably small for delivery labels. I am in doubts if its 
redundancy is high enough to reliably recognize it if it would be 
scratched during delivery. Another limitation may be stability of 
optics in scanners in respect to labels. This one is printed using a 
laser printer with resolution at least 600 dpi. Each QR code pixel has 
still 4x4 printer dots in the case of 300dpi, so when image is 
properly aligned, printer quality is not an issue. 


Standard thermal label printers are 203DPI (8 dots per mm).

The problem with printing QR codes and bar codes is not the resolution 
of the printer but getting the the software drivers to produce a bitmap 
that is the same resolution as the printer resolution and aligned at the 
pixel level when it goes to the printer


I have written a CUPS driver for a thermal printer and routinely print 
labels with barcodes and QR style codes. I have immense problems with 
PDF labels generated by my local postal service which are generated for 
a 300 DPI printer. The barcodes especially end up with too thick or too 
thin bars where the pixel mapping doesn't align. These will not scan.


I have asked the postal service to generate labels at 203dpi which will 
print just fine at 600 dpi and so work with laser and thermal printers, 
but they will not cooperate.


I am in the process of developing software to take the issued labels, 
extract the barcode and QR fields, decode them, and then generate new 
bitmaps at 203 dpi to replace  the misaligned bitmaps. This is not 
straight forward as the postal service does not fully comply with the 
coding rules.


In the meantime I have to extract the QR and bar code fields, enlarge 
them, and print on separate labels.


As far as printer drivers work, CUPS typically generates a bitmap from a 
source document such as PDF or postscript, and passes that to a raster 
printer. This in itself can be a problem as any stage of the process of 
generation of pdf, 'printing', and rasterisation can misalign and 
distort pixels. To be absolutely sure of clean output you need a custom 
program directly driving the printer.

Re: printing QR-codes on labels with 300dpi label printers with LaTeX

[Max Nikulin]

On 09/03/2024 19:08, hw wrote:

On Fri, 2024-03-08 at 23:21 +0700, Max Nikulin wrote:

On 08/03/2024 12:35, hw wrote:

On Thu, 2024-03-07 at 23:15 -0500, Jeffrey Walton wrote:


I have a USB thermal printer for the shipping labels,
.


This printer has only 300dpi.  If you print QR-codes on it make sure
you can scan them: they have to be large enough or get you an
unscanable smear.


I believed that 300dpi is high enough resolution for QR-codes of
reasonable size if source image has proper quality. On the other hand,
if possible, it is better to scale QR-codes to match some whole factor
of printer pixel size.


What do you consider a 'reasonable size'?


Looking at a QR code likely having ~75 pixels per inch I find it 
unreasonably small for delivery labels. I am in doubts if its redundancy 
is high enough to reliably recognize it if it would be scratched during 
delivery. Another limitation may be stability of optics in scanners in 
respect to labels. This one is printed using a laser printer with 
resolution at least 600 dpi. Each QR code pixel has still 4x4 printer 
dots in the case of 300dpi, so when image is properly aligned, printer 
quality is not an issue.



There is no source image other than whatever LaTeX creates.  I can
specify the size of the QR-code.  Other than that, how do you apply
scaling?


I am unsure what particular QR code generator do you use and what is the 
format of QR codes. Is it raster or vector image? Specify size that 
makes QR code pixels having whole number of printer pixels.


"Fit to page" or "fit to printable area" in printer options may make an 
image blurry. In the case of low input image resolution, upscaling 
method suitable for photos may make QR code blurry. However consistent 
configuration should make QR codes sharp.

Re: printing problem, markdown files

[gene heskett]

On 2/1/24 15:31, Dan Ritter wrote:

gene heskett wrote:

On 2/1/24 12:24, Dan Ritter wrote:

gene heskett wrote:
pandoc -f markdown FILEIN.md -t pdf -o FILEOUT.pdf

will turn markdown into PDF, which you can probably print, if by
no other means than FTP to the printer itself. (Try it, Brothers
come with this by default.)



Thanks DSR.

Scanning thru the docs I don't see anything that looks like what the print
job shops of the last century called a "binding ditch".  That is where the
output file has say a 15mm blank space inserted on the left edge of odd
numbered pages, while that same 15mm of blank space is inserted to the right
of the text on even pages, leave a blank area to perfect bind the duplex
pages w/o burying the text into the center crack of the opened pages. Have
they adopted a new name for this?


Printers (the people) still call it that.

You will also want to install latex ( apt install texlive-extra-utils
will get you what you need)

pandoc options:

-V geometry:margin=1in

(all four sides)

-V geometry:left=3cm,right=3cm,top=2cm,bottom=2cm

(separate values for each side)

and finally, what you probably want:

-V geometry:twoside,left=15mm,right=30mm,top=2cm,bottom=3cm

I just tested that and it did a pretty nice job. My actual
command:

pandoc -f markdown -t pdf -V 
geometry:twoside,left=15mm,right=30mm,top=2cm,bottom=3cm test.md -o foo.pdf

-dsr-

Downright tasty stuff, thank you dsr.

.


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: printing problem, markdown files

[Dan Ritter]

gene heskett wrote: 
> On 2/1/24 12:24, Dan Ritter wrote:
> > gene heskett wrote:
> > pandoc -f markdown FILEIN.md -t pdf -o FILEOUT.pdf
> > 
> > will turn markdown into PDF, which you can probably print, if by
> > no other means than FTP to the printer itself. (Try it, Brothers
> > come with this by default.)
> > 
> 
> Thanks DSR.
> 
> Scanning thru the docs I don't see anything that looks like what the print
> job shops of the last century called a "binding ditch".  That is where the
> output file has say a 15mm blank space inserted on the left edge of odd
> numbered pages, while that same 15mm of blank space is inserted to the right
> of the text on even pages, leave a blank area to perfect bind the duplex
> pages w/o burying the text into the center crack of the opened pages. Have
> they adopted a new name for this?

Printers (the people) still call it that. 

You will also want to install latex ( apt install texlive-extra-utils 
will get you what you need)

pandoc options:

-V geometry:margin=1in

(all four sides)

-V geometry:left=3cm,right=3cm,top=2cm,bottom=2cm

(separate values for each side)

and finally, what you probably want: 

-V geometry:twoside,left=15mm,right=30mm,top=2cm,bottom=3cm

I just tested that and it did a pretty nice job. My actual
command:

pandoc -f markdown -t pdf -V 
geometry:twoside,left=15mm,right=30mm,top=2cm,bottom=3cm test.md -o foo.pdf

-dsr-

Re: printing problem, markdown files

[gene heskett]

On 2/1/24 12:24, Dan Ritter wrote:

gene heskett wrote:

debian bookworm everting updated earlier this morning.

I have an about 125 page .md file I need hardcopy of.


If you don't have pandoc installed:

sudo apt install pandoc

then:

pandoc -f markdown FILEIN.md -t pdf -o FILEOUT.pdf

will turn markdown into PDF, which you can probably print, if by
no other means than FTP to the printer itself. (Try it, Brothers
come with this by default.)

pandoc will translate all sorts of formats into many other
formats; if you don't want PDF, HTML, docx, rtf and even epub
are available.

-dsr-


Thanks DSR.

Scanning thru the docs I don't see anything that looks like what the 
print job shops of the last century called a "binding ditch".  That is 
where the output file has say a 15mm blank space inserted on the left 
edge of odd numbered pages, while that same 15mm of blank space is 
inserted to the right of the text on even pages, leave a blank area to 
perfect bind the duplex pages w/o burying the text into the center crack 
of the opened pages. Have they adopted a new name for this?


Take care, stay well

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: printing problem, markdown files

[Teemu Likonen]

* 2024-02-01 11:57:50-0500, gene heskett wrote:

> I have an about 125 page .md file I need hardcopy of.

Maybe install "okular" and "okular-extra-backends" which includes
markdown backend. Open your .md file in Okular which then renders it
nicely. Print.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: printing problem, markdown files

[Dan Ritter]

gene heskett wrote: 
> debian bookworm everting updated earlier this morning.
> 
> I have an about 125 page .md file I need hardcopy of.

If you don't have pandoc installed:

sudo apt install pandoc

then:

pandoc -f markdown FILEIN.md -t pdf -o FILEOUT.pdf

will turn markdown into PDF, which you can probably print, if by
no other means than FTP to the printer itself. (Try it, Brothers
come with this by default.)

pandoc will translate all sorts of formats into many other
formats; if you don't want PDF, HTML, docx, rtf and even epub
are available.

-dsr-

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

On Mon  6 Jun 2022, at 20:03, Gareth Evans  wrote:
> On Mon  6 Jun 2022, at 17:45, Gareth Evans  wrote:
>> Recent message with screenshots didn't get through (at least yet) - 
>> text below, plus another observation.
>>
>> On Mon  6 Jun 2022, at 16:53, Gareth Evans  wrote:
>>> On Mon  6 Jun 2022, at 16:23, Eduardo M KALINOWSKI 
>>>  wrote:
 On 06/06/2022 10:48, Gareth Evans wrote:
> Not sure what's happened though as it worked perfectly with both 
> auto-detected and manually-added printer profiles from Bullseye until a 
> week or two ago.  My logs suggest no update to system-config-printer.  I 
> did change the printer's hostname (on printer console) but both the 
> printer and laptop have been restarted several times since then, printers 
> re-added and re-auto-detected etc.

 In my case it never worked any other way. But I never dug very deep to 
 try to find out why.

> Why should adding via the command line work, but not via 
> system-config-printer or localhost:631?

 I guess adding it in CUPS web interface (localhost:631) should work, if 
 the exact same parameters are selected: the ipp:// url and the "CUPS PPD 
 generator" (selected by "-m everywhere" option) as opposed to 
 "cups-filters PPD generator".

 That might be the explanation (at least for my case). From what I 
 understand from https://wiki.debian.org/CUPSDriverlessPrinting , there 
 are those two options, and "The cups-filters PPD generator is used by 
 default with cups-browsed". In theory either should work, but there's 
 probably some quirk in the printer and some small difference between the 
 two methods.

 -- 
 Tchurin-tchurin-tchun-clain!

 -- Chapolim

 Eduardo M KALINOWSKI
 edua...@kalinowski.com.br
>>>
>>> When adding a printer with system-config-printer, it is detected and 
>>> listed under "Network Printer" in the list (when expanded) (twice).  I 
>>> currently see what's in the screenshots attached, but sometimes the 
>>> "IPP network printer via DNS-SD" connection option changes to something 
>>> involving AppSocket/... at the beginning.  
>>>
>>> There seem to be different connections available at different times.
>>>
>>> Any ideas why that should be?
>>>
>>> It seems to me that something has changed.  Given the problem was the 
>>> same with an identical printer on a different network, I guess it's 
>>> something to do with CUPS (or its config) rather than the printer 
>>> itself misbehaving.  I had factory-reset it a couple of days ago.
>>>
>>> Thanks,
>>> Gareth
>>>
>>>
>>> Attachments:
>>> * Screenshot at 2022-06-06 16-39-52.png
>>> * Screenshot at 2022-06-06 16-40-03.png
>>
>> $ driverless list
>> DEBUG: Started ippfind (PID 95003)
>> "driverless:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" en 
>> "Brother" "Brother MFC-L2740DW series, driverless, cups-filters 1.28.7" 
>> "MFG:Brother;MDL:MFC-L2740DW series;CMD:PWGRaster,AppleRaster,URF,PWG;"
>> "driverless-fax:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" 
>> en "Brother" "Brother MFC-L2740DW series, Fax, driverless, cups-filters 
>> 1.28.7" "MFG:Brother;MDL:MFC-L2740DW 
>> series;CMD:PWGRaster,AppleRaster,URF,PWG;"
>> DEBUG: ippfind (PID 95003) exited with no errors.
>>
>> The error log except attached earlier includes:
>>
>> [line no] log text
>> [30] D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-is-accepting-jobs 
>> boolean true
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state enum idle
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state-reasons keyword 
>> none
>> D [06/Jun/2022:13:32:04 +0100] [Job 6]  end-of-attributes-tag 
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] IPP/2.0 Get-Job-Attributes #22
>> D [06/Jun/2022:13:32:04 +0100] [Job 6]  operation-attributes-tag 
>> 
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-charset charset utf-8
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-natural-language 
>> naturalLanguage en-gb
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-uri uri 
>> ipp://mfcl2740dw.local:631/ipp/faxout
>> 
>>   ^^
>> 
>>Fax
>>
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-id integer 82
>> 
>> D [06/Jun/2022:13:32:04 +0100] [Job 6]  unsupported-attributes-tag 
>> 
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] requested-attributes keyword 
>> job-media-sheets-completed
>> D [06/Jun/2022:13:32:04 +0100] [Job 6]  job-attributes-tag 
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-id integer 82
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-impressions-completed 
>> integer 0
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-name nameWithoutLanguage 
>> Test Page
>> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-originating-user-name 
>> nameWithoutLanguage user
>> D [06/Jun/2022:13:3

Re: Printing the old way

[Joel Roth]

On Tue, Jun 14, 2022 at 04:59:36PM -0400, pa...@quillandmouse.com wrote:
> Folks:
> 
> Back in the dark days of early Linux, before CUPS, we printed with
> printers all the time. There was an infrastructure for doing this. Does
> anyone remember how that worked? As in, what packages were needed, etc.?

Using magicfilter with lprng lets you print a variety of 
file types. 

-- 
Joel Roth

Re: Printing the old way

[Christian Groessler]

On 6/14/22 23:11, Klaus Singvogel wrote:

Additional you needed printer specific drivers, if you don't have a
PostScript capable printer.



You could use ghostscript as filter if you didn't have a PS capable 
printer. (Which was normal because they were expensive).



regards,
chris

Re: Printing the old way

[David Wright]

On Tue 14 Jun 2022 at 23:25:32 (+0200), Thomas Schmitt wrote:
> Paul M. Foster wrote:
> > > Back in the dark days of early Linux, before CUPS, we printed with
> > > printers all the time. There was an infrastructure for doing this. Does
> > > anyone remember how that worked? As in, what packages were needed, etc.?
> 
> Greg Wooledge wrote:
> > lprng was the most common one, I think.  As the name implies, that one
> > is the "next generation" of lpr, the old BSD tool.
> 
> "printcap" is another term which pops up from my 1990s memories.
> There still exist lpr and lprng as Debian packages:
>   lpr: /usr/share/man/man5/printcap.5.gz
>   lprng: /usr/share/man/man5/printcap.5.gz

My notes from bo (1.3) mention a program called checkpc. You edited
the files /etc/lpd.{conf,perms} and /etc/printcap, and then ran
checkpc (as user) and checkpc -f (as root) to set it all up.

Cheers,
David.

Re: Printing the old way

[IL Ka]

Old printer connected via LPT port was accessed using /dev/lpt
Because several processes shouldn't print at the same time, there was a
spooler called lpd and the client tool called lpr.

https://www.linuxtopia.org/online_books/linux_system_administration/linux_printer_HOWTO/setup_002.html


On Tue, Jun 14, 2022 at 11:00 PM  wrote:

> Folks:
>
> Back in the dark days of early Linux, before CUPS, we printed with
> printers all the time. There was an infrastructure for doing this. Does
> anyone remember how that worked? As in, what packages were needed, etc.?
>
> Paul
>
> --
> Paul M. Foster
> Personal Blog: http://noferblatz.com
> Company Site: http://quillandmouse.com
> Software Projects: https://gitlab.com/paulmfoster
>
>

Re: Printing the old way

[Bijan Soleymani]

On 6/14/2022 4:59 PM, pa...@quillandmouse.com wrote:

Folks:

Back in the dark days of early Linux, before CUPS, we printed with
printers all the time. There was an infrastructure for doing this. Does
anyone remember how that worked? As in, what packages were needed, etc.?


If you want to do this for practical reasons and not for nostalgia's sake then 
you can make a RAW spool/queue printer in CUPS. And then use the command line 
cups command as lp/lpr.

As in the olden days you'll have to make sure what you're sending to the 
printer is in some format it understands.

Unless you have a really weird printer or printer setup cthough you're better 
off having cups to the conversion to printer format for you.

https://stackoverflow.com/questions/26329186/creating-a-raw-printer-queue-in-cups-host-and-adding-them-through-cups-client

https://www.cups.org/doc/options.html

Bijan

Re: Printing the old way

[Thomas Schmitt]

Hi,

Paul M. Foster wrote:
> > Back in the dark days of early Linux, before CUPS, we printed with
> > printers all the time. There was an infrastructure for doing this. Does
> > anyone remember how that worked? As in, what packages were needed, etc.?

Greg Wooledge wrote:
> lprng was the most common one, I think.  As the name implies, that one
> is the "next generation" of lpr, the old BSD tool.

"printcap" is another term which pops up from my 1990s memories.
There still exist lpr and lprng as Debian packages:
  lpr: /usr/share/man/man5/printcap.5.gz
  lprng: /usr/share/man/man5/printcap.5.gz


Have a nice day :)

Thomas

Re: Printing the old way

[Klaus Singvogel]

pa...@quillandmouse.com wrote:
> Back in the dark days of early Linux, before CUPS, we printed with
> printers all the time. There was an infrastructure for doing this. Does
> anyone remember how that worked? As in, what packages were needed, etc.?

LPRng was the most common printing spooler before CUPS.

Additional you needed printer specific drivers, if you don't have a
PostScript capable printer.

But I cant remember anymore how to setup these things - around 20 years
have passed.

I have doubts that programs like libreoffice, gimp, or PDF readers will
still work without CUPS. But don't know for sure.

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: Printing the old way

[Greg Wooledge]

On Tue, Jun 14, 2022 at 04:59:36PM -0400, pa...@quillandmouse.com wrote:
> Back in the dark days of early Linux, before CUPS, we printed with
> printers all the time. There was an infrastructure for doing this. Does
> anyone remember how that worked? As in, what packages were needed, etc.?

lprng was the most common one, I think.  As the name implies, that one
is the "next generation" of lpr, the old BSD tool.

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

On Mon  6 Jun 2022, at 17:45, Gareth Evans  wrote:
> Recent message with screenshots didn't get through (at least yet) - 
> text below, plus another observation.
>
> On Mon  6 Jun 2022, at 16:53, Gareth Evans  wrote:
>> On Mon  6 Jun 2022, at 16:23, Eduardo M KALINOWSKI 
>>  wrote:
>>> On 06/06/2022 10:48, Gareth Evans wrote:
 Not sure what's happened though as it worked perfectly with both 
 auto-detected and manually-added printer profiles from Bullseye until a 
 week or two ago.  My logs suggest no update to system-config-printer.  I 
 did change the printer's hostname (on printer console) but both the 
 printer and laptop have been restarted several times since then, printers 
 re-added and re-auto-detected etc.
>>>
>>> In my case it never worked any other way. But I never dug very deep to 
>>> try to find out why.
>>>
 Why should adding via the command line work, but not via 
 system-config-printer or localhost:631?
>>>
>>> I guess adding it in CUPS web interface (localhost:631) should work, if 
>>> the exact same parameters are selected: the ipp:// url and the "CUPS PPD 
>>> generator" (selected by "-m everywhere" option) as opposed to 
>>> "cups-filters PPD generator".
>>>
>>> That might be the explanation (at least for my case). From what I 
>>> understand from https://wiki.debian.org/CUPSDriverlessPrinting , there 
>>> are those two options, and "The cups-filters PPD generator is used by 
>>> default with cups-browsed". In theory either should work, but there's 
>>> probably some quirk in the printer and some small difference between the 
>>> two methods.
>>>
>>> -- 
>>> Tchurin-tchurin-tchun-clain!
>>>
>>> -- Chapolim
>>>
>>> Eduardo M KALINOWSKI
>>> edua...@kalinowski.com.br
>>
>> When adding a printer with system-config-printer, it is detected and 
>> listed under "Network Printer" in the list (when expanded) (twice).  I 
>> currently see what's in the screenshots attached, but sometimes the 
>> "IPP network printer via DNS-SD" connection option changes to something 
>> involving AppSocket/... at the beginning.  
>>
>> There seem to be different connections available at different times.
>>
>> Any ideas why that should be?
>>
>> It seems to me that something has changed.  Given the problem was the 
>> same with an identical printer on a different network, I guess it's 
>> something to do with CUPS (or its config) rather than the printer 
>> itself misbehaving.  I had factory-reset it a couple of days ago.
>>
>> Thanks,
>> Gareth
>>
>>
>> Attachments:
>> * Screenshot at 2022-06-06 16-39-52.png
>> * Screenshot at 2022-06-06 16-40-03.png
>
> $ driverless list
> DEBUG: Started ippfind (PID 95003)
> "driverless:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" en 
> "Brother" "Brother MFC-L2740DW series, driverless, cups-filters 1.28.7" 
> "MFG:Brother;MDL:MFC-L2740DW series;CMD:PWGRaster,AppleRaster,URF,PWG;"
> "driverless-fax:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" 
> en "Brother" "Brother MFC-L2740DW series, Fax, driverless, cups-filters 
> 1.28.7" "MFG:Brother;MDL:MFC-L2740DW 
> series;CMD:PWGRaster,AppleRaster,URF,PWG;"
> DEBUG: ippfind (PID 95003) exited with no errors.
>
> The error log except attached earlier includes:
>
> [line no] log text
> [30] D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-is-accepting-jobs 
> boolean true
> D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state enum idle
> D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state-reasons keyword 
> none
> D [06/Jun/2022:13:32:04 +0100] [Job 6]  end-of-attributes-tag 
> D [06/Jun/2022:13:32:04 +0100] [Job 6] IPP/2.0 Get-Job-Attributes #22
> D [06/Jun/2022:13:32:04 +0100] [Job 6]  operation-attributes-tag 
> 
> D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-charset charset utf-8
> D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-natural-language 
> naturalLanguage en-gb
> D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-uri uri 
> ipp://mfcl2740dw.local:631/ipp/faxout
> 
>   ^^
> 
>Fax
>
> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-id integer 82
> 
> D [06/Jun/2022:13:32:04 +0100] [Job 6]  unsupported-attributes-tag 
> 
> D [06/Jun/2022:13:32:04 +0100] [Job 6] requested-attributes keyword 
> job-media-sheets-completed
> D [06/Jun/2022:13:32:04 +0100] [Job 6]  job-attributes-tag 
> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-id integer 82
> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-impressions-completed 
> integer 0
> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-name nameWithoutLanguage 
> Test Page
> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-originating-user-name 
> nameWithoutLanguage user
> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-state enum canceled
> D [06/Jun/2022:13:32:04 +0100] [Job 6] job-state-reasons keyword 
> job-canceled-at-device"
> 

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

Recent message with screenshots didn't get through (at least yet) - text below, 
plus another observation.

On Mon  6 Jun 2022, at 16:53, Gareth Evans  wrote:
> On Mon  6 Jun 2022, at 16:23, Eduardo M KALINOWSKI 
>  wrote:
>> On 06/06/2022 10:48, Gareth Evans wrote:
>>> Not sure what's happened though as it worked perfectly with both 
>>> auto-detected and manually-added printer profiles from Bullseye until a 
>>> week or two ago.  My logs suggest no update to system-config-printer.  I 
>>> did change the printer's hostname (on printer console) but both the printer 
>>> and laptop have been restarted several times since then, printers re-added 
>>> and re-auto-detected etc.
>>
>> In my case it never worked any other way. But I never dug very deep to 
>> try to find out why.
>>
>>> Why should adding via the command line work, but not via 
>>> system-config-printer or localhost:631?
>>
>> I guess adding it in CUPS web interface (localhost:631) should work, if 
>> the exact same parameters are selected: the ipp:// url and the "CUPS PPD 
>> generator" (selected by "-m everywhere" option) as opposed to 
>> "cups-filters PPD generator".
>>
>> That might be the explanation (at least for my case). From what I 
>> understand from https://wiki.debian.org/CUPSDriverlessPrinting , there 
>> are those two options, and "The cups-filters PPD generator is used by 
>> default with cups-browsed". In theory either should work, but there's 
>> probably some quirk in the printer and some small difference between the 
>> two methods.
>>
>> -- 
>> Tchurin-tchurin-tchun-clain!
>>
>> -- Chapolim
>>
>> Eduardo M KALINOWSKI
>> edua...@kalinowski.com.br
>
> When adding a printer with system-config-printer, it is detected and 
> listed under "Network Printer" in the list (when expanded) (twice).  I 
> currently see what's in the screenshots attached, but sometimes the 
> "IPP network printer via DNS-SD" connection option changes to something 
> involving AppSocket/... at the beginning.  
>
> There seem to be different connections available at different times.
>
> Any ideas why that should be?
>
> It seems to me that something has changed.  Given the problem was the 
> same with an identical printer on a different network, I guess it's 
> something to do with CUPS (or its config) rather than the printer 
> itself misbehaving.  I had factory-reset it a couple of days ago.
>
> Thanks,
> Gareth
>
>
> Attachments:
> * Screenshot at 2022-06-06 16-39-52.png
> * Screenshot at 2022-06-06 16-40-03.png

$ driverless list
DEBUG: Started ippfind (PID 95003)
"driverless:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" en "Brother" 
"Brother MFC-L2740DW series, driverless, cups-filters 1.28.7" 
"MFG:Brother;MDL:MFC-L2740DW series;CMD:PWGRaster,AppleRaster,URF,PWG;"
"driverless-fax:ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" en 
"Brother" "Brother MFC-L2740DW series, Fax, driverless, cups-filters 1.28.7" 
"MFG:Brother;MDL:MFC-L2740DW series;CMD:PWGRaster,AppleRaster,URF,PWG;"
DEBUG: ippfind (PID 95003) exited with no errors.

The error log except attached earlier includes:

[line no] log text
[30] D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-is-accepting-jobs boolean 
true
D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state enum idle
D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-state-reasons keyword none
D [06/Jun/2022:13:32:04 +0100] [Job 6]  end-of-attributes-tag 
D [06/Jun/2022:13:32:04 +0100] [Job 6] IPP/2.0 Get-Job-Attributes #22
D [06/Jun/2022:13:32:04 +0100] [Job 6]  operation-attributes-tag 
D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-charset charset utf-8
D [06/Jun/2022:13:32:04 +0100] [Job 6] attributes-natural-language 
naturalLanguage en-gb
D [06/Jun/2022:13:32:04 +0100] [Job 6] printer-uri uri 
ipp://mfcl2740dw.local:631/ipp/faxout

  ^^

   Fax

D [06/Jun/2022:13:32:04 +0100] [Job 6] job-id integer 82

D [06/Jun/2022:13:32:04 +0100] [Job 6]  unsupported-attributes-tag 
D [06/Jun/2022:13:32:04 +0100] [Job 6] requested-attributes keyword 
job-media-sheets-completed
D [06/Jun/2022:13:32:04 +0100] [Job 6]  job-attributes-tag 
D [06/Jun/2022:13:32:04 +0100] [Job 6] job-id integer 82
D [06/Jun/2022:13:32:04 +0100] [Job 6] job-impressions-completed integer 0
D [06/Jun/2022:13:32:04 +0100] [Job 6] job-name nameWithoutLanguage Test Page
D [06/Jun/2022:13:32:04 +0100] [Job 6] job-originating-user-name 
nameWithoutLanguage user
D [06/Jun/2022:13:32:04 +0100] [Job 6] job-state enum canceled
D [06/Jun/2022:13:32:04 +0100] [Job 6] job-state-reasons keyword 
job-canceled-at-device"
 
^^

...even though it wasn't (at least not by me).

Does any of this suggest it's presenting/being auto-detected as (only) a fax 
machine ... and cancelling the

Re: Printing problem (was snapshot.debian.org)

[Eduardo M KALINOWSKI]

On 06/06/2022 10:48, Gareth Evans wrote:

Not sure what's happened though as it worked perfectly with both auto-detected 
and manually-added printer profiles from Bullseye until a week or two ago.  My 
logs suggest no update to system-config-printer.  I did change the printer's 
hostname (on printer console) but both the printer and laptop have been 
restarted several times since then, printers re-added and re-auto-detected etc.


In my case it never worked any other way. But I never dug very deep to 
try to find out why.



Why should adding via the command line work, but not via system-config-printer 
or localhost:631?


I guess adding it in CUPS web interface (localhost:631) should work, if 
the exact same parameters are selected: the ipp:// url and the "CUPS PPD 
generator" (selected by "-m everywhere" option) as opposed to 
"cups-filters PPD generator".


That might be the explanation (at least for my case). From what I 
understand from https://wiki.debian.org/CUPSDriverlessPrinting , there 
are those two options, and "The cups-filters PPD generator is used by 
default with cups-browsed". In theory either should work, but there's 
probably some quirk in the printer and some small difference between the 
two methods.


--
Tchurin-tchurin-tchun-clain!

-- Chapolim

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

On Mon  6 Jun 2022, at 14:14, Eduardo M KALINOWSKI  
wrote:
> On 06/06/2022 08:19, Gareth Evans wrote:
>> Hello,
>> 
>> I have a strange printing problem which can be replicated on two identical 
>> printers on two different networks, when printing to wireless driverless IPP 
>> with Brother MFC-L2740DW printers from Bullseye, whether the printer is 
>> auto-detected or manually added via ocalhost:631 or system-config-printer.
>
> I have this exact printer. Driverless printing works, but not with the 
> automatically generated entry included by cups-browsed (or some other 
> package), i have to manually add a printer queue using
>
> # lpinfo -v
>
> to get a list of URLs (the one starting with ipp:// is the one 
> necessary), and then something like
>
> # lpadmin -p Brother2740 -v IPP_URL_FROM_ABOVE -E -m everywhere
>
>

That worked, and it's now printing normally after reboot via the added profile, 
thank you Eduardo.  

Not sure what's happened though as it worked perfectly with both auto-detected 
and manually-added printer profiles from Bullseye until a week or two ago.  My 
logs suggest no update to system-config-printer.  I did change the printer's 
hostname (on printer console) but both the printer and laptop have been 
restarted several times since then, printers re-added and re-auto-detected etc.

HTTP_STATE_WAITING Closing for error 32 (Broken pipe)

- appears in the error log for jobs it is now actually printing, so that seems 
to be unrelated.

I don't like it when things stop working without explanation.  

Why should adding via the command line work, but not via system-config-printer 
or localhost:631?

Any further debugging tips would be appreciated.

Thanks,
Gareth



> -- 
> BOFH excuse #201:
>
> RPC_PMAP_FAILURE
>
> Eduardo M KALINOWSKI
> edua...@kalinowski.com.br

Re: Printing problem (was snapshot.debian.org)

[Eduardo M KALINOWSKI]

On 06/06/2022 08:19, Gareth Evans wrote:

Hello,

I have a strange printing problem which can be replicated on two identical 
printers on two different networks, when printing to wireless driverless IPP 
with Brother MFC-L2740DW printers from Bullseye, whether the printer is 
auto-detected or manually added via ocalhost:631 or system-config-printer.


I have this exact printer. Driverless printing works, but not with the 
automatically generated entry included by cups-browsed (or some other 
package), i have to manually add a printer queue using


# lpinfo -v

to get a list of URLs (the one starting with ipp:// is the one 
necessary), and then something like


# lpadmin -p Brother2740 -v IPP_URL_FROM_ABOVE -E -m everywhere


--
BOFH excuse #201:

RPC_PMAP_FAILURE

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

CUPS error log excerpt attached.
G


On Mon  6 Jun 2022, at 14:02, Gareth Evans  wrote:
> On Mon  6 Jun 2022, at 13:05, rhkra...@gmail.com wrote:
>> On Monday, June 06, 2022 07:34:07 AM Gareth Evans wrote:
>>> On Mon  6 Jun 2022, at 12:19, Gareth Evans  wrote:
>>> > I have a strange printing problem which can be replicated on two
>>> > identical printers on two different networks, when printing to wireless
>>> > driverless IPP with Brother MFC-L2740DW printers from Bullseye, whether
>>> > the printer is auto-detected or manually added via ocalhost:631 or
>>> > system-config-printer.
>>
>> Is there a facility to run a test print directly from the printer?  If so, 
>> does that work?
>
> Hello,
>
> Yes, the printer prints test pages and reports from its own console, 
> and documents via wifi from my iphone, but not from Debian.  Even 11.0 
> with non-updated cups.  Same issue with an identical printer on another 
> network - that does print from Buster.  I half suspected a router 
> problem, but same issues when Bullseye laptop and my printer are linked 
> via iphone wifi hotspot.  Same issue when my Bullseye laptop is linked 
> via EE mobile broadband router (locally) to an identical printer (in 
> another place, 10 miles away, so can't check for differences regularly).
>
> After using system-config-printer to print a test page on an 
> auto-detected driverless IPP profile, connected via 2.5GHz wifi to a 
> router, to which the Bullseye laptop is connected via 5GHz wifi, I get 
> no output, and:
>
> $ lpstat -t
> scheduler is running
> no system default destination
> device for Brother_MFC_L2740DW_series: 
> implicitclass://Brother_MFC_L2740DW_series/
> Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 
> 13:12:54 BST
> printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 
> 2022 13:12:54 BST
>   No suitable destination host found by cups-browsed.
> Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 
> 13:12:48 BST
>
> After changing laptop to 2.5GHz wifi...
>
> $ lpstat -t
> scheduler is running
> no system default destination
> device for Brother_MFC_L2740DW_series: 
> implicitclass://Brother_MFC_L2740DW_series/
> Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 
> 13:14:40 BST
> printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 
> 2022 13:14:40 BST
>   Printer disappeared or cups-browsed shutdown
> Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 
> 13:12:48 BST
>
> $ sudo systemctl status cups-browsed
> [sudo] password for user: 
> ● cups-browsed.service - Make remote CUPS printers available locally
>  Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; 
> vendor >
>  Active: active (running) since Mon 2022-06-06 13:04:25 BST; 11min ago
>Main PID: 1666 (cups-browsed)
>   Tasks: 3 (limit: 14146)
>  Memory: 3.8M
> CPU: 209ms
>  CGroup: /system.slice/cups-browsed.service
>  └─1666 /usr/sbin/cups-browsed
>
> Jun 06 13:04:25 qwerty systemd[1]: Started Make remote CUPS printers 
> available >
>
> *I deleted 5GHz wifi profile from Network Manager Edit Connections*
> $ sudo reboot
>
> $ sudo systemctl status cups-browsed
> [sudo] password for user: 
> ● cups-browsed.service - Make remote CUPS printers available locally
>  Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; 
> vendor >
>  Active: active (running) since Mon 2022-06-06 13:27:27 BST; 3min 13s ago
>Main PID: 2059 (cups-browsed)
>   Tasks: 3 (limit: 14146)
>  Memory: 2.9M
> CPU: 100ms
>  CGroup: /system.slice/cups-browsed.service
>  └─2059 /usr/sbin/cups-browsed
>
> Jun 06 13:27:27 qwerty systemd[1]: Started Make remote CUPS printers 
> available >
> lines 1-11/11 (END)
>
>
> $ lpstat -t
> scheduler is running
> no system default destination
> device for Brother_MFC_L2740DW_series: 
> implicitclass://Brother_MFC_L2740DW_series/
> Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 
> 13:27:46 BST
> printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 
> 2022 13:27:46 BST
>   Printer disappeared or cups-browsed shutdown
> Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 
> 13:12:48 BST
>
> *Turned printer off and on again*
>
> $ lpstat -t
> scheduler is running
> no system default destination
> device for Brother_MFC_L2740DW_series: 
> implicitclass://Brother_MFC_L2740DW_series/
> Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 
> 13:31:39 BST
> printer Brother_MFC_L2740DW_series now printing 
> Brother_MFC_L2740DW_series-6.  enabled since Mon 06 Jun 2022 13:31:39 
> BST
>   Waiting for job to complete.
> Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 
> 13:12:48 BST
>
>
> $ lpstat -t
> scheduler is running
> no system default destination
> device for Brother_MFC_L2740DW_series: 
> implicitclass://Brother_MFC_L27

Re: Printing problem (was snapshot.debian.org)

[Gareth Evans]

On Mon  6 Jun 2022, at 13:05, rhkra...@gmail.com wrote:
> On Monday, June 06, 2022 07:34:07 AM Gareth Evans wrote:
>> On Mon  6 Jun 2022, at 12:19, Gareth Evans  wrote:
>> > I have a strange printing problem which can be replicated on two
>> > identical printers on two different networks, when printing to wireless
>> > driverless IPP with Brother MFC-L2740DW printers from Bullseye, whether
>> > the printer is auto-detected or manually added via ocalhost:631 or
>> > system-config-printer.
>
> Is there a facility to run a test print directly from the printer?  If so, 
> does that work?

Hello,

Yes, the printer prints test pages and reports from its own console, and 
documents via wifi from my iphone, but not from Debian.  Even 11.0 with 
non-updated cups.  Same issue with an identical printer on another network - 
that does print from Buster.  I half suspected a router problem, but same 
issues when Bullseye laptop and my printer are linked via iphone wifi hotspot.  
Same issue when my Bullseye laptop is linked via EE mobile broadband router 
(locally) to an identical printer (in another place, 10 miles away, so can't 
check for differences regularly).

After using system-config-printer to print a test page on an auto-detected 
driverless IPP profile, connected via 2.5GHz wifi to a router, to which the 
Bullseye laptop is connected via 5GHz wifi, I get no output, and:

$ lpstat -t
scheduler is running
no system default destination
device for Brother_MFC_L2740DW_series: 
implicitclass://Brother_MFC_L2740DW_series/
Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 13:12:54 BST
printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 2022 
13:12:54 BST
No suitable destination host found by cups-browsed.
Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 13:12:48 
BST

After changing laptop to 2.5GHz wifi...

$ lpstat -t
scheduler is running
no system default destination
device for Brother_MFC_L2740DW_series: 
implicitclass://Brother_MFC_L2740DW_series/
Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 13:14:40 BST
printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 2022 
13:14:40 BST
Printer disappeared or cups-browsed shutdown
Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 13:12:48 
BST

$ sudo systemctl status cups-browsed
[sudo] password for user: 
● cups-browsed.service - Make remote CUPS printers available locally
 Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor >
 Active: active (running) since Mon 2022-06-06 13:04:25 BST; 11min ago
   Main PID: 1666 (cups-browsed)
  Tasks: 3 (limit: 14146)
 Memory: 3.8M
CPU: 209ms
 CGroup: /system.slice/cups-browsed.service
 └─1666 /usr/sbin/cups-browsed

Jun 06 13:04:25 qwerty systemd[1]: Started Make remote CUPS printers available >

*I deleted 5GHz wifi profile from Network Manager Edit Connections*
$ sudo reboot

$ sudo systemctl status cups-browsed
[sudo] password for user: 
● cups-browsed.service - Make remote CUPS printers available locally
 Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor >
 Active: active (running) since Mon 2022-06-06 13:27:27 BST; 3min 13s ago
   Main PID: 2059 (cups-browsed)
  Tasks: 3 (limit: 14146)
 Memory: 2.9M
CPU: 100ms
 CGroup: /system.slice/cups-browsed.service
 └─2059 /usr/sbin/cups-browsed

Jun 06 13:27:27 qwerty systemd[1]: Started Make remote CUPS printers available >
lines 1-11/11 (END)


$ lpstat -t
scheduler is running
no system default destination
device for Brother_MFC_L2740DW_series: 
implicitclass://Brother_MFC_L2740DW_series/
Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 13:27:46 BST
printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 2022 
13:27:46 BST
Printer disappeared or cups-browsed shutdown
Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 13:12:48 
BST

*Turned printer off and on again*

$ lpstat -t
scheduler is running
no system default destination
device for Brother_MFC_L2740DW_series: 
implicitclass://Brother_MFC_L2740DW_series/
Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 13:31:39 BST
printer Brother_MFC_L2740DW_series now printing Brother_MFC_L2740DW_series-6.  
enabled since Mon 06 Jun 2022 13:31:39 BST
Waiting for job to complete.
Brother_MFC_L2740DW_series-6 user  1024   Mon 06 Jun 2022 13:12:48 
BST


$ lpstat -t
scheduler is running
no system default destination
device for Brother_MFC_L2740DW_series: 
implicitclass://Brother_MFC_L2740DW_series/
Brother_MFC_L2740DW_series accepting requests since Mon 06 Jun 2022 13:32:06 BST
printer Brother_MFC_L2740DW_series is idle.  enabled since Mon 06 Jun 2022 
13:32:06 BST

But nothing printed.

/var/log/cups/error_log attached for most recent test page.
(/etc/cups/cupsd.conf loglevel = debug)

Re: printing pages in reverse order not possible in LO 7.2.5.2.0+

[Ken Heard]

On 2022-02-13 18:09, Ken Heard wrote:
In order to print documents on both sides of the paper using a printer 
without collating ability, I always printed first in reverse order the 
even pages.  I then  print in numerical order the odd pages on the back 
side of the paper on which the even pages are printed.  In this way the 
pages do not need to be collated manually.


While this version of LO still allows printing separately the odd and 
even pages, I discovered to my horror that it no longer allows printing 
of pages in reverse order.


The help page however still says that all one has to do to print in 
reverse order is to


1.    Choose File - Print.
2.    Click the General tab.
3.    Choose Print in reverse page order.
4.    Click Print.

In view of the foregoing it would appear that disappearance of the 
reverse print option was unintended.  In that case when can we helpless 
users expect this error to be corrected?


I don't know how I managed to miss the 'More' which causes the 'Print in 
reverse order' option to emerge.  In fact there are two 'Mores', one for 
'Range and Copies' and the other for 'Page Layout' .  The first one 
opens more options most of which I cannot use because the printer I am 
using is a simplex.  The one option I can use and want to use is "Print 
in reverse order'.  (I am not too sure what additional
options the second 'more' opens; they mostly seem to relate to 
collations which a simplex printer cannot do.)


I must however in my defence say that in the help entry for reverse 
printing there is no reference to the first 'more'.  I naturally 
inferred that an intermediate step was not necessary, as it probably was 
at some point in the dim and distant past.  I assume it likely that help 
revisions lag behind changes in the software, understandable.  The 
general layout of the print window could nevertheless stand improvement.


In any event many thanks to all for your help, in particular for Dave 
Barton's screen shot which made everything crystal clear.


Regards, Ken

Re: Printing lots of pages skips a few

[Pankaj Jangid]

mick crane  writes:

> May be an issue with the printer reporting it has printed file when it
> hasn't.
> Perhaps try wait between each print instruction.
>

This could be one reason. But I am not sure how to diagnose
this. Perhaps the procedure suggested by David is a good starting point.

Regards ~Pankaj

Re: Printing lots of pages skips a few

[Pankaj Jangid]

David Wright  writes:

> And in the OP's case, this might save a little effort, because my
> next step in the investigation would be to check the files in
> /var/spool/cups/c* to make sure that all the files had actually
> been queued. If so, what does each file report as happening.
> (The files are timestamped, so their later repeat printings can
> be discounted.)
>
> The OP might want to sort on date and/or sequence number if they
> were going to bother to sort at all. The sort options are
> complicated a little by the choice of ddmmyy, rather than yymmdd,
> for the date field.
>

Thanks for these pointers, David. Today I am travelling. Tomorrow, I’ll
definitely diagnose using the procedure outlined by you.

Regards ~Pankaj

Re: Printing lots of pages skips a few

[David Wright]

On Tue 01 Feb 2022 at 07:29:09 (-0500), Greg Wooledge wrote:
> On Tue, Feb 01, 2022 at 03:04:06PM +0530, Pankaj Jangid wrote:
> > I tried to print ~40 pages using the following combination of commands:
> > 
> > find . -name "pref***.pdf" | xargs lp
> > 
> > The result was that a couple of pages were missed.
> 
> That command is fundamentally broken.  It will fail if any of the
> matching filenames contain whitespace, single quotes or double quotes.
> 
> A correct version would be:
> 
> find . -name "pref*.pdf" -exec lp {} +
> 
> That's the preferred one.  If you're really old-fashioned and just cannot
> live without xargs, the first thing you must realize is that POSIX xargs
> is fundamentally incapable of doing this correctly.  GNU xargs has a -0
> extension, though, which makes it possible:
> 
> find . -name "pref*.pdf" -print0 | xargs -0 lp
> 
> That one is acceptable, albeit longer, less efficient and less portable.

(… goes off to check .bashrc, and comes back …)

I find frequent use of xargs, and they're almost all on account of

needing  …  -print0 | LC_ALL=C sort -z | xargs -0 …  (± the locale).

And in the OP's case, this might save a little effort, because my
next step in the investigation would be to check the files in
/var/spool/cups/c* to make sure that all the files had actually
been queued. If so, what does each file report as happening.
(The files are timestamped, so their later repeat printings can
be discounted.)

The OP might want to sort on date and/or sequence number if they
were going to bother to sort at all. The sort options are
complicated a little by the choice of ddmmyy, rather than yymmdd,
for the date field.

Cheers,
David.

Re: Printing lots of pages skips a few

[Curt]

On 2022-02-02, mick crane  wrote:
>> 
>> Also I could identify and print those files separately; using "lp
>> ".
>
> May be an issue with the printer reporting it has printed file when it 
> hasn't.  Perhaps try wait between each print instruction.

It would be edifying to examine, at the very least, the actual command
used rather than the substituted "example" command given (for reasons
which escape your corresondant), as well as a list of the files that
failed to print.


> mick
>

Re: Printing lots of pages skips a few

[mick crane]

On 2022-02-02 10:42, Pankaj Jangid wrote:

Klaus Singvogel  writes:


Can you look at the webinterface of CUPS regarding the missing jobs?

http://localhost:631/

-> Printer -> select your default printer (if more) -> finish job (or
similar)


I did that when I discovered that some pages were missing. Nothing 
there

in unfinished jobs.

Also I could identify and print those files separately; using "lp
".



May be an issue with the printer reporting it has printed file when it 
hasn't.

Perhaps try wait between each print instruction.

mick

--
Key ID4BFEBB31

Re: Printing lots of pages skips a few

[Pankaj Jangid]

Klaus Singvogel  writes:

> Can you look at the webinterface of CUPS regarding the missing jobs?
>
>   http://localhost:631/
>
> -> Printer -> select your default printer (if more) -> finish job (or
> similar)

I did that when I discovered that some pages were missing. Nothing there
in unfinished jobs.

Also I could identify and print those files separately; using "lp
".

Regards ~Pankaj

Re: Printing lots of pages skips a few

[Pankaj Jangid]

Greg Wooledge  writes:

> I can't help noticing that none of your filenames begin with "pref",
> so none of them actually match the -name pattern that's being given
> to find.  One of the obvious ways you could experience this problem
> is that the "missing" files don't match the pattern you're using.

That "pref" was just an example in the original post. I none of the
files bypassed the pattern.

> Beyond that, perhaps some of the files are empty (either literally
> zero bytes, or they contain only "comments" or metadata that doesn't
> cause the generation of images using ink on paper when printed).
>
> Or... the files aren't readable due to permissions.  Or they're not in
> the directories you think they're in.
>
> Can you identify *which* files aren't being visibly printed?  By process
> of elimination, you should be able to find out.  Pick one of them, and
> analyze the situation.  If it's not an issue with the name, location or
> permissions, then try to open it with a PDF viewer.  If it opens correctly,
> try printing it with "lp".

I could identify and print those files separately later, using "lp
" command.

Re: Printing lots of pages skips a few

[Klaus Singvogel]

Pankaj Jangid wrote:
> 
> In my case though, I had verified that the output of find is okay for
> xargs. Then I added | xargs lp.
> 
> But could this be cause of missing page. The output of find is:
> 
> --8<---cut here---start->8---
[...]
> --8<---cut here---end--->8---
> 
> six of them were not printed.

Can you look at the webinterface of CUPS regarding the missing jobs?

http://localhost:631/

-> Printer -> select your default printer (if more) -> finish job (or similar)

Regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: Printing lots of pages skips a few

[Greg Wooledge]

On Tue, Feb 01, 2022 at 10:42:31PM +0530, Pankaj Jangid wrote:
> Greg Wooledge  writes:
> > A correct version would be:
> >
> > find . -name "pref*.pdf" -exec lp {} +

> Thanks for this brief course, Greg. I really liked it.
> 
> In my case though, I had verified that the output of find is okay for
> xargs. Then I added | xargs lp.
> 
> But could this be cause of missing page. The output of find is:
> 
> --8<---cut here---start->8---
> 2018/letters/060718I049905433.pdf
> 2018/letters/250518I049904099.pdf
> 2018/letters/150918I049901510.pdf
[..]

OK.  Then there must be something else wrong.

I can't help noticing that none of your filenames begin with "pref",
so none of them actually match the -name pattern that's being given
to find.  One of the obvious ways you could experience this problem
is that the "missing" files don't match the pattern you're using.

Beyond that, perhaps some of the files are empty (either literally
zero bytes, or they contain only "comments" or metadata that doesn't
cause the generation of images using ink on paper when printed).

Or... the files aren't readable due to permissions.  Or they're not in
the directories you think they're in.

Can you identify *which* files aren't being visibly printed?  By process
of elimination, you should be able to find out.  Pick one of them, and
analyze the situation.  If it's not an issue with the name, location or
permissions, then try to open it with a PDF viewer.  If it opens correctly,
try printing it with "lp".

Re: Printing lots of pages skips a few

[Pankaj Jangid]

Greg Wooledge  writes:

> On Tue, Feb 01, 2022 at 03:04:06PM +0530, Pankaj Jangid wrote:
>> I tried to print ~40 pages using the following combination of commands:
>> 
>> find . -name "pref***.pdf" | xargs lp
>> 
>> The result was that a couple of pages were missed.
>
> That command is fundamentally broken.  It will fail if any of the
> matching filenames contain whitespace, single quotes or double quotes.
>
> A correct version would be:
>
> find . -name "pref*.pdf" -exec lp {} +
>
> That's the preferred one.  If you're really old-fashioned and just cannot
> live without xargs, the first thing you must realize is that POSIX xargs
> is fundamentally incapable of doing this correctly.  GNU xargs has a -0
> extension, though, which makes it possible:
>
> find . -name "pref*.pdf" -print0 | xargs -0 lp
>
> That one is acceptable, albeit longer, less efficient and less portable.

Thanks for this brief course, Greg. I really liked it.

In my case though, I had verified that the output of find is okay for
xargs. Then I added | xargs lp.

But could this be cause of missing page. The output of find is:

--8<---cut here---start->8---
2018/letters/060718I049905433.pdf
2018/letters/250518I049904099.pdf
2018/letters/150918I049901510.pdf
2018/letters/180518I049903135.pdf
2018/letters/180518I049902524.pdf
2018/letters/191018I049905432.pdf
2018/letters/300718I049902173.pdf
2018/letters/141218I049903816.pdf
2018/letters/261018I049903737.pdf
2018/letters/290618I049904628.pdf
2018/letters/190718I049902138.pdf
2018/letters/230718I049900093.pdf
2018/letters/030818I049903843.pdf
2018/letters/190118I049901374.pdf
2018/letters/150618I049903232.pdf
2018/letters/281218I049903776.pdf
2018/letters/190118I049901373.pdf
2018/letters/240818I049904062.pdf
2018/letters/121218I049903419.pdf
2018/letters/201118I049900883.pdf
2018/letters/021118I049904149.pdf
2018/letters/111018I049901537.pdf
2018/letters/270718I049903199.pdf
2018/letters/211218I049904184.pdf
2018/letters/180518I049902534.pdf
2018/letters/261118I049905674.pdf
2018/letters/210918I049902234.pdf
2018/letters/210918I049906208.pdf
2018/letters/230818I049902830.pdf
2018/letters/150518I049903258.pdf
2018/letters/261018I049903715.pdf
2018/letters/100918I049902331.pdf
2018/letters/180818I049904319.pdf
2018/letters/110518I049903217.pdf
2018/letters/290118I049905290.pdf
2018/letters/121018I049903705.pdf
2018/letters/170518I049901548.pdf
2018/letters/180818I049904094.pdf
2018/letters/191218I049901286.pdf
2018/letters/101018I049905261.pdf
2018/letters/021118I049904059.pdf
2018/letters/060118I049902467.pdf
2018/letters/150618I049903254.pdf
2018/letters/110518I049903022.pdf
2018/letters/270718I049903443.pdf
2018/letters/240818I049904852.pdf
2018/letters/210918I049906209.pdf
2018/letters/300518I049903175.pdf
2018/letters/280918I049901364.pdf
2018/letters/140918I049906491.pdf
2018/letters/010618I049902892.pdf
2018/letters/060618I049904019.pdf
2018/letters/070918I049903663.pdf
2018/letters/301118I049903918.pdf
2018/letters/261018I049901520.pdf
--8<---cut here---end--->8---

six of them were not printed.

Regards ~Pankaj

Re: Printing lots of pages skips a few

[Greg Wooledge]

On Tue, Feb 01, 2022 at 03:04:06PM +0530, Pankaj Jangid wrote:
> I tried to print ~40 pages using the following combination of commands:
> 
> find . -name "pref***.pdf" | xargs lp
> 
> The result was that a couple of pages were missed.

That command is fundamentally broken.  It will fail if any of the
matching filenames contain whitespace, single quotes or double quotes.

A correct version would be:

find . -name "pref*.pdf" -exec lp {} +

That's the preferred one.  If you're really old-fashioned and just cannot
live without xargs, the first thing you must realize is that POSIX xargs
is fundamentally incapable of doing this correctly.  GNU xargs has a -0
extension, though, which makes it possible:

find . -name "pref*.pdf" -print0 | xargs -0 lp

That one is acceptable, albeit longer, less efficient and less portable.

Re: printing in Debian 11; was bullseye fusses.

[peter]

From: Gene Heskett 
Date: Sat, 11 Dec 2021 18:11:28 -0800
> ... does it [debian-printing] exist?

Gene, in case you didn't catch this earlier, posting again with 
reference corrected. 

The current problem might be solved.  If another surfaces in the 
future, debian-printing might be more efficient than debian-user. 

https://lists.debian.org/debian-printing/

Regards,   ... P.

-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

Re: printing in Debian 11; was bullseye fusses.

[peter]

From: Gene Heskett 
Date: Sat, 11 Dec 2021 18:11:28 -0800
> ... does [debian-printing] exist?

https://lists.debian.org/debian-printing/

Regards,   ... P.

-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

Re: Printing bug: which package to report?

[David Jarvie]

On Sunday, 3 October 2021 18:01:32 -0700 Peter Ehlert wrote:
> On 10/3/21 3:01 PM, David Jarvie wrote:
> > I've found a new printing bug which I want to report, but I don't know
> > which package to report against.
> > 
> > My Samsung M2885FW printer now always prints double sided even when I set
> > the duplex print parameter to Off. This is on Debian Bullseye. It didn't
> > happen when Bullseye was first released in August.
> 
> can you edit the settings with CUPS?
> 
> http://localhost:631/admin/

It is already configured with duplex off in CUPS (Two-sided: None, and Reverse 
Two-sided: None). Duplex is shown as off both in the print dialog options and 
in the CUPS configuration. Note that this happens when printing both from a KDE 
application (Okular) and from LibreOffice, which use different print dialogs. 
So 
it doesn't seem to be an application issue, but rather an issue in some print-
related package.

> > Can someone please tell me which package to enter in the bug report?

Re: Printing bug: which package to report?

[Peter Ehlert]

On 10/3/21 3:01 PM, David Jarvie wrote:

I've found a new printing bug which I want to report, but I don't know which
package to report against.

My Samsung M2885FW printer now always prints double sided even when I set the
duplex print parameter to Off. This is on Debian Bullseye. It didn't happen
when Bullseye was first released in August.


can you edit the settings with CUPS?

http://localhost:631/admin/



Can someone please tell me which package to enter in the bug report?

Re: Printing addresses on a #10 envelope (US)?

[Curt]

On 2021-05-11,   wrote:
>
> That is so near a wordplay that I wonder whether it was
> intentional. Envelopers who use developes?
>

To develop is to free from that which envelops; envelop denotes to
enclose or enfold whereas develop means to unfold, make visible.
The two terms in their primary senses are antithetical.

It wasn't near wordplay; it was definitely a *calembour*.

Re: Printing addresses on a #10 envelope (US)?

[Curt]

On 2021-05-10, Nate Bargmann  wrote:
>
> The Insert->Envelope dialog allows one to properly choose the #10
> envelope and the resulting document looks correct.  Then when opening
> the Print dialog the formatting becomes stuck on the C5 size.  Even
> resetting to #10 (or Com-10) results in the address blocks being placed
> too low on the envelope.  Tips from the 'Net have failed me.
>

Someone has reported success via the Format/Page menu items and then
simply selecting #10 envelope, rather than going the Insert->Envelope
route. 

Re: Printing addresses on a #10 envelope (US)?

[tomas]

On Tue, May 11, 2021 at 12:44:03PM -0400, Michael Stone wrote:
> On Tue, May 11, 2021 at 11:26:01AM -0500, Nate Bargmann wrote:
> >This must be a tough bug to resolve as this one has been open almost 9
> >years:
> >
> >https://bugs.documentfoundation.org/show_bug.cgi?id=51132
> 
> It's probably hard to find developers who use envelopes

That is so near a wordplay that I wonder whether it was
intentional. Envelopers who use developes?

Anyway, thanks for it ;-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Printing addresses on a #10 envelope (US)?

[Russell L. Harris]

On Tue, May 11, 2021 at 10:10:22AM -0500, David Wright wrote:

I still have clean fanfold labels that they jettisoned after lining
up the lineprinters all those years ago.


Beware David; label adhesives may die with age.  Old fanfold labels
likely will not adhere, and labels applied five to ten years ago pop
free when the file folder is flexed.  I learned the hard way, with
file cabinets full of unlabeled file folders.

Archivial labels are available, with a non-aging adhesive.

RLH

Re: Printing addresses on a #10 envelope (US)?

[Michael Stone]

On Tue, May 11, 2021 at 11:26:01AM -0500, Nate Bargmann wrote:

This must be a tough bug to resolve as this one has been open almost 9
years:

https://bugs.documentfoundation.org/show_bug.cgi?id=51132


It's probably hard to find developers who use envelopes

Re: Printing addresses on a #10 envelope (US)?

[deloptes]

David Wright wrote:

>> 
>> And the year is 1998 :D
> 
> You can go back two more decades. I recall writing a stand-alone
> program to print a learned society's mailing labels on a Decwriter.
> For me it was an exercise, as I had only written OS360/370 assembler
> to extend FortranIV until then. For the subscription secretary, it
> enabled a faster turnround as we didn't have to persuade the operators
> to load sticky labels on their busy lineprinters. Less waste too:
> I still have clean fanfold labels that they jettisoned after lining
> up the lineprinters all those years ago.

around 1998 you could already print with other tools than lpr or lprng.
When I listen to you guys I have a respect, but you must understand that
time goes on - this is like advertising Mercedes Benz from 1930 and telling
me how cool this car was ... well might be, might be, but no one needs this
anymore - except the museum.

So I just wanted to make a joke :)

In fact if you want to read such posts more often you should subscribe to
RPi mailing list comp.sys.raspberry-pi. It's mostly like this - very little
epistemological benefit for the reader, but amusing.

Re: Printing addresses on a #10 envelope (US)?

[Nate Bargmann]

This must be a tough bug to resolve as this one has been open almost 9
years:

https://bugs.documentfoundation.org/show_bug.cgi?id=51132

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Printing addresses on a #10 envelope (US)?

[David Wright]

On Tue 11 May 2021 at 00:17:12 (+0200), deloptes wrote:
> Russell L. Harris wrote:
> 
> > I use a dot-matrix printer with tractor feed to print self-adhesive
> > address labels.  There is no formatting; just several lines of plain
> > text, one address per file.  There is no driver; the printer is
> > managed by CUPS to receive "raw" data.  I print labels using the "lpr"
> > command.
> 
> And the year is 1998 :D

You can go back two more decades. I recall writing a stand-alone
program to print a learned society's mailing labels on a Decwriter.
For me it was an exercise, as I had only written OS360/370 assembler
to extend FortranIV until then. For the subscription secretary, it
enabled a faster turnround as we didn't have to persuade the operators
to load sticky labels on their busy lineprinters. Less waste too:
I still have clean fanfold labels that they jettisoned after lining
up the lineprinters all those years ago.

Cheers,
David.

Re: Printing addresses on a #10 envelope (US)?

[deloptes]

to...@tuxteam.de wrote:

>> However lpr ...
>> ... Neanderthals get extinct at some point of
>> time ;-)
> 
> ...perhaps /because/ they moved from lprng to CUPS ;-(=)

there was no compatible interface in production anymore :)

Re: Printing addresses on a #10 envelope (US)?

[tomas]

On Tue, May 11, 2021 at 09:43:37AM +0200, deloptes wrote:

[...]

> However lpr ... 
> ... Neanderthals get extinct at some point of
> time ;-)

...perhaps /because/ they moved from lprng to CUPS ;-(=)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Printing addresses on a #10 envelope (US)?

[deloptes]

to...@tuxteam.de wrote:

> Yeah. Today you would use a client-server architecture, the server
> being an npm application running in a Docker container. The client
> is based on libelectron (the printer selection dialog has to have
> a GUI, after all). Since the stack of dependencies is so, well,
> hellish, you better deploy your print-capable apps as Flatpaks [0],
> each one with its own copy of libelectron (and of Chrome, of course).
> 
> Makes you pine for the good ol' times where those things were made
> with Eclipse [1].
> 
> Nah. I'll take lprng, thankyouverymuch.

the dot matrix printer from Epson, I bought in 1996 for ~100 US$ still works
pretty well and the tape is very cheap.

However lpr ... come on - even RPi or a refurbished PC with a display is
more handy. You do not have to go into the other extreme with flatpack ...
but command line ... come on ... Neanderthals get extinct at some point of
time ;-)

Re: Printing addresses on a #10 envelope (US)?

[tomas]

On Tue, May 11, 2021 at 12:17:12AM +0200, deloptes wrote:
> Russell L. Harris wrote:
> 
> > I use a dot-matrix printer with tractor feed to print self-adhesive
> > address labels.  There is no formatting; just several lines of plain
> > text, one address per file.  There is no driver; the printer is
> > managed by CUPS to receive "raw" data.  I print labels using the "lpr"
> > command.
> 
> And the year is 1998 :D

Yeah. Today you would use a client-server architecture, the server
being an npm application running in a Docker container. The client
is based on libelectron (the printer selection dialog has to have
a GUI, after all). Since the stack of dependencies is so, well,
hellish, you better deploy your print-capable apps as Flatpaks [0],
each one with its own copy of libelectron (and of Chrome, of course).

Makes you pine for the good ol' times where those things were made
with Eclipse [1].

Nah. I'll take lprng, thankyouverymuch.

Cheers
[0] Or however your application isolation framework is called
   in the circle of hell you currently inhabit.
[1] And I thought Eclipse had its name because lights went dim
   when it was started. Naive me.

 - t


signature.asc
Description: Digital signature

Re: Printing addresses on a #10 envelope (US)?

[Russell L. Harris]

On Mon, May 10, 2021 at 09:24:48PM -0500, Nate Bargmann wrote:

* On 2021 10 May 16:05 -0500, Russell L. Harris wrote:

I use a dot-matrix printer with tractor feed to print self-adhesive
address labels.  There is no formatting; just several lines of plain
text, one address per file.  There is no driver; the printer is
managed by CUPS to receive "raw" data.  I print labels using the "lpr"
command.


Oh wow, memories!

In the summer of 1990 while going to electronics school I bought a
Panasonic KX-P1124 24 pin dot matrix printer.  That set me back a few
hundred bucks at the time but it was worth it to be able to submit near
letter quality lab reports and schematic drawings.

I used it for several years afterward until I bought a Deskjet (one and
done with that tech) and then bartered my way into a laser printer.  I
don't recall if I gave the '1124 away or sent it to recycling several
years ago.  :-(


It is cheap; it is easy and simple for one-off jobs (For labels I use
the editor "nano".); a box of 5000 tractor-feed labels lasts for ever,
even if you must print two or three duplicates to get to the tear-off
point.  The only down-side is the table space (I leave mine set up),
and the fact that if you don't use it every few weeks, the ribbon
dries out a little.  My OKI Microline 320 connects via USB.

RLH

Re: Printing addresses on a #10 envelope (US)?

[Nate Bargmann]

* On 2021 10 May 16:05 -0500, Russell L. Harris wrote:
> I use a dot-matrix printer with tractor feed to print self-adhesive
> address labels.  There is no formatting; just several lines of plain
> text, one address per file.  There is no driver; the printer is
> managed by CUPS to receive "raw" data.  I print labels using the "lpr"
> command.

Oh wow, memories!

In the summer of 1990 while going to electronics school I bought a
Panasonic KX-P1124 24 pin dot matrix printer.  That set me back a few
hundred bucks at the time but it was worth it to be able to submit near
letter quality lab reports and schematic drawings.

I used it for several years afterward until I bought a Deskjet (one and
done with that tech) and then bartered my way into a laser printer.  I
don't recall if I gave the '1124 away or sent it to recycling several
years ago.  :-(

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Printing addresses on a #10 envelope (US)?

[Nate Bargmann]

* On 2021 10 May 15:13 -0500, deloptes wrote:
> I use very often the Apaches OpenOffice 4.1.7 (version ATM) to print
> envelopes. then as suggested I use the manual tray of the HP 420dn which I
> have here to print it. It works OOB. Here is the process
> 1. select the page size Menu -> Format -> Page (Page Format -> Format #10)
> 2. Write the address
> 3. Set the manual tray (1) on the 420dn and insert the envelope
> 4. Print

And right here is where it starts replacing #10 with C5 in the current
LO 7.0.4.2 in Bullseye.

> What you describe looks like issue with margins and why are you trying
> OpenOffice 3.3?! Even my version is already outdated

This goes back some years where I had an old set of spreadsheets
starting in 2003 and carried them forward year to year.  With some newer
version of LO, may have been 5.x, it was doing strange things to those
sheets.  I also had a special work flow I used once per year that worked
in that old version but changes in newer versions of LO resulted in that
it was faster to stuff that old version in /opt and run it from time to
time.

I no longer do either work flow any longer but I just left that old
version there.  My attempt was to see if this may have been a new bug in
LO.  I don't think so as I got the same buggy behavior of it wanting to
use the C5 size rather than #10.  Apparently this is long standing as I
found questions about this very thing going back several years in Web
searches.

Perhaps this has been fixed in AOO and I should try a newer version.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Printing addresses on a #10 envelope (US)?

[Nate Bargmann]

Interesting tip, Glenn.

I've used Impress but not Draw much.  While I do have envelopes that I
will be printing the same address on a regular basis, it is the one-off
jobs that I'd like to use something simpler, I guess, or at least ready
made.  Sometime the current Writer bug needs to be addressed.  I guess I
should start poking around for the LO bug database.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Printing addresses on a #10 envelope (US)?

[deloptes]

Russell L. Harris wrote:

> I use a dot-matrix printer with tractor feed to print self-adhesive
> address labels.  There is no formatting; just several lines of plain
> text, one address per file.  There is no driver; the printer is
> managed by CUPS to receive "raw" data.  I print labels using the "lpr"
> command.

And the year is 1998 :D

Re: Printing addresses on a #10 envelope (US)?

[Russell L. Harris]

On Mon, May 10, 2021 at 10:36:57AM -0500, Nate Bargmann wrote:

Are there other options?  Looking about I don't see any.  Even the
online Google Docs does not appear to have any support for printing
envelopes.  I understand most people do things online but there is still
a reason to use snail mail and representing an organization, my
handwriting is poor enough that it is better served via printing
envelopes.


I use a dot-matrix printer with tractor feed to print self-adhesive
address labels.  There is no formatting; just several lines of plain
text, one address per file.  There is no driver; the printer is
managed by CUPS to receive "raw" data.  I print labels using the "lpr"
command.

RLH

Re: Printing addresses on a #10 envelope (US)?

[deloptes]

Nate Bargmann wrote:

> I've successfully used the current version of Libre Office in Testing to
> print mailing addresses on a #6 3/4 (US) envelope and so wanted to do
> the same with a #10 (US) envelope, and have had nothing but frustration
> for almost the past two hours.
> 
> The Insert->Envelope dialog allows one to properly choose the #10
> envelope and the resulting document looks correct.  Then when opening
> the Print dialog the formatting becomes stuck on the C5 size.  Even
> resetting to #10 (or Com-10) results in the address blocks being placed
> too low on the envelope.  Tips from the 'Net have failed me.
> 
> I even tried a static linked version of Open Office 3.3 I have installed
> and it has the same bug!  Obviously, this is long-standing bug and
> probably won't be fixed any time soon, certainly not in the Bullseye
> time frame.
> 
> Are there other options?  Looking about I don't see any.  Even the
> online Google Docs does not appear to have any support for printing
> envelopes.  I understand most people do things online but there is still
> a reason to use snail mail and representing an organization, my
> handwriting is poor enough that it is better served via printing
> envelopes.

I use very often the Apaches OpenOffice 4.1.7 (version ATM) to print
envelopes. then as suggested I use the manual tray of the HP 420dn which I
have here to print it. It works OOB. Here is the process
1. select the page size Menu -> Format -> Page (Page Format -> Format #10)
2. Write the address
3. Set the manual tray (1) on the 420dn and insert the envelope
4. Print

What you describe looks like issue with margins and why are you trying
OpenOffice 3.3?! Even my version is already outdated

Re: Printing addresses on a #10 envelope (US)?

[ghe2001]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256





‐‐‐ Original Message ‐‐‐
On Monday, May 10, 2021 9:36 AM, Nate Bargmann  wrote:

> Hi All.
>
> I've successfully used the current version of Libre Office in Testing to
> print mailing addresses on a #6 3/4 (US) envelope and so wanted to do
> the same with a #10 (US) envelope, and have had nothing but frustration
> for almost the past two hours.
>
> The Insert->Envelope dialog allows one to properly choose the #10
> envelope and the resulting document looks correct. Then when opening
> the Print dialog the formatting becomes stuck on the C5 size. Even
> resetting to #10 (or Com-10) results in the address blocks being placed
> too low on the envelope. Tips from the 'Net have failed me.

Here's yet another tip from the 'Net :-)

I have an elderly HP 4240n laser printer.  If I pull down the 'door' on the 
front, there's a place with guides where I can put an envelope.

A long time ago, I used the the Page program on a Mac -- it had no problem 
doing envelopes.  I can't find a civilized way to do them on LO.

So I use LO's Draw, set for a full sheet of paper (8.5 * 11 US letter -- don't 
remember what it's called).  I measured the envelope, created a long rectangle 
of that size, centered in the upper area of the page, put some text blocks in 
it for To and From, wrote in the blocks, and rotated them.  There was some 
futzing to position the envelope rectangle in the right place (IIRC, margins 
also need some modification), but with the rest of the page empty, Draw prints 
perfect envelopes.  It's a mild pain, but it beats writing.  And I had to do it 
only once.

--
Glenn English
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJgmXlFACEJEJ/XhjGCrIwyFiEELKJzD0JScCVjQA2Xn9eG
MYKsjDK2yQf/eXM2YcSci6VsZAY/AalSIZ1XtiaNmYOs0Elnv+adHEP3uEcK
/Loi7cnKHvcPX6fMxcTxDRmvLSgD+TQkarKmlAeMOpaSu9J0Hwh3oF8Le+An
EsR7RNtdfnfYiXtOfcpqFl+b0ltEwzWRff0wQ+Ja3MipBR8q1IJjd1Cl9OZr
KnVUIP7pkAxYOQqPa1TVDsA8vV7I2EOlenrNj0+O2IyqVBsEJHbhEIKNYY+2
cfD5AuziMQxGYPCKmnGUZO/qGBtuv3eIEf4gdxerA3QxNDAoCkHRny4Qog4h
/hsF5TXW2zP4rfFKiXjmtJmvGZ30mp3It18BecKrUySr62bMlnO2cA==
=Htzu
-END PGP SIGNATURE-

Re: printing on a remote usb printer

[Pierre Frenkiel]

On Thu, 12 Dec 2019, Brian wrote:


This looks good. We take it that you can print from *the server*?

  yes, of course...


'lp -d ljp /etc/nsswitch.conf' saves you a bit of ink/toner.


  thank you for the tip


At last, I found the origin of the problem:

  wrong "order" entries in /etc/cups/cupsd.conf
  as I thought that the 1st parameter was the default, but actually the default 
one is the 2nd!

  I had
 order allow,deny
  and the correct order should be
 order deny,allow

thank you Brian for your collaboration: I suppose that the cupsenable and 
cupsaccept you gave me
are not useless. I'll check that on an other client.

best regards,
--
Pierre Frenkiel

Re: printing on a remote usb printer

[Brian]

On Thu 12 Dec 2019 at 18:50:04 +0100, Pierre Frenkiel wrote:

> On Thu, 12 Dec 2019, Brian wrote:
> 
> > Post what you get for 'lpstat -t' on server and client.
> 
> I only left entries for the involved printer

That's fine.

> on the server:
> 
>scheduler is running
>system default destination: ljp
>device for ljp: hp:/usb/HP_LaserJet_MFP_M227-M231?serial=VNC3P21987
>ljp accepting requests since Thu 12 Dec 2019 06:33:27 PM CET
>printer ljp is idle.  enabled since Thu 12 Dec 2019 06:33:27 PM CET

This looks good. We take it that you can print from *the server*?
'lp -d ljp /etc/nsswitch.conf' saves you a bit of ink/toner.
 
> on the client:
> 
>scheduler is running
>system default destination: ljp
>device for ljp: ipp://pfr2/printers/ljp

pfr2 is the hostname of the server? If so, that should be ok if the
client can resolve it. Try pfr2.local or the IP in the server URI.

>ljp not accepting requests since Thu 12 Dec 2019 09:02:47 AM CET -
>   reason unknown

If in doubt, do 'cupsenable ljp' and 'cupsaccept ljp'

>printer ljp is idle.  enabled since Thu 12 Dec 2019 09:02:47 AM CET
> 
>I noticed, in/var/log/cups/error_log(server side)
>  Returning HTTP Forbidden for Get-Printer-Attributes 
> (ipp://pfr2.local:631/printers/ljp) from 192.168.1.163
> 
>and the client:
>   Returning IPP server-error-not-accepting-jobs for Create-Job 
> (ipp://localhost/printers/ljp) from localhost.

Would you also do 'ippfind -T 5'? (-T 5 may not be needed).

-- 
Brian.

Re: printing on a remote usb printer

[Pierre Frenkiel]

On Thu, 12 Dec 2019, Brian wrote:


Post what you get for 'lpstat -t' on server and client.


I only left entries for the involved printer

on the server:

   scheduler is running
   system default destination: ljp
   device for ljp: hp:/usb/HP_LaserJet_MFP_M227-M231?serial=VNC3P21987
   ljp accepting requests since Thu 12 Dec 2019 06:33:27 PM CET
   printer ljp is idle.  enabled since Thu 12 Dec 2019 06:33:27 PM CET

on the client:

   scheduler is running
   system default destination: ljp
   device for ljp: ipp://pfr2/printers/ljp
   ljp not accepting requests since Thu 12 Dec 2019 09:02:47 AM CET -
  reason unknown
   printer ljp is idle.  enabled since Thu 12 Dec 2019 09:02:47 AM CET

   I noticed, in/var/log/cups/error_log(server side)
 Returning HTTP Forbidden for Get-Printer-Attributes 
(ipp://pfr2.local:631/printers/ljp) from 192.168.1.163

   and the client:
  Returning IPP server-error-not-accepting-jobs for Create-Job 
(ipp://localhost/printers/ljp) from localhost.

Re: printing on a remote usb printer

[Brian]

On Wed 11 Dec 2019 at 22:30:01 +0100, Pierre Frenkiel wrote:

> hi,
> I'm trying to configure a print queue using a remote usb printer.
> I found on Internet the following recommended config:
> 
>DeviceURI ipp://192.168.1.12:631/printers/ljp
> 
> but it doesn't work: I get "the printer is not responding"
> Idem without :631.
> I suppose that something is missing or wrong, on the server or the client
> side, but what?

Post what you get for 'lpstat -t' on server and client.

-- 
Brian.

Re: printing on a remote usb printer

[Charles Curley]

On Wed, 11 Dec 2019 22:30:01 +0100 (CET)
Pierre Frenkiel  wrote:

> I'm trying to configure a print queue using a remote usb printer.
> I found on Internet the following recommended config:
> 
> DeviceURI ipp://192.168.1.12:631/printers/ljp

I'm going to assume you've adjusted the URI to suit your local
situation. That includes both the IP address and the name and path of
the printer.

Did you use CUPS to set up the printer and the printer queue?
Discovering USB printers on other machines seems to be built in to CUPS
these days. First, be sure the printer is shareable.
http://localhost:631/help/sharing.html?QUERY=sharing

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Printing impossible

[Brian]

On Tue 27 Mar 2018 at 10:28:29 +0200, MENGUAL Jean-Philippe wrote:

> Ok now I am completely blocked. It results from the thread on the
> bugreport that:
> - I tried all I was advised, it does not work
> - The upstream devs explain Debian is responsible
> - No answer from Debian Printing team.

Your initial report was responded to on Sat 24 Mar 2018 and you were
cc'ed. I'd advise that you update the report with details on what you
have tried and how it turned out.

Fwiw, the command provided to you by upstream:

  gs -sDEVICE=tiff24nc -sOutputFile=out.tif input.pdf

runs without error here on unstable.

-- 
Brian.

Re: Printing impossible

[MENGUAL Jean-Philippe]

Hi,

Ok now I am completely blocked. It results from the thread on the
bugreport that:
- I tried all I was advised, it does not work
- The upstream devs explain Debian is responsible
- No answer from Debian Printing team.

Well, I am out of idea and, as often, people upstream explain it is
Debian :D Not easy to hope fixing easily such problems.

Thanks very much for your further help.

Best regards,

signature_jp_2
Logo Hypra  JEAN-PHILIPPE MENGUAL
DIRECTEUR TECHNIQUE ET QUALITÉ
102, rue des poissonniers, 75018, Paris
Tel : +331 84 73 06 61  Mob : +336 76 34 93 37

jpmeng...@hypra.fr 
www.hypra.fr 
Facebook Hypra  Twitter Hypra
 Linkedin Jean-Philippe



Le 26/03/2018 à 05:51, MENGUAL Jean-Philippe a écrit :
>
> Logo HypraJEAN-PHILIPPE MENGUAL
> DIRECTEUR TECHNIQUE ET QUALITÉ
> 102, rue des poissonniers, 75018, Paris
> Tel : +331 84 73 06 61  Mob : +336 76 34 93 37
> 
> jpmeng...@hypra.fr 
> www.hypra.fr 
> Facebook Hypra  Twitter Hypra
>  Linkedin Jean-Philippe
> 
>
>
>
> Le 26/03/2018 à 01:17, Brian a écrit :
>> On Sun 25 Mar 2018 at 22:51:25 +0200, MENGUAL Jean-Philippe wrote:
>>
>>> Le 25/03/2018 à 19:05, Brian a écrit :
 On Sun 25 Mar 2018 at 11:29:38 +0200, MENGUAL Jean-Philippe wrote:

>> I'll add that I set up a queue with
>>
>>   lpadmin - p 1750 -v file:/dev/null -E -m 
>> drv:///splix-samsung.drv/ml1750.ppd
>>
>> and printed the test page from the CUPS web interface. All filters
>> completed without any errors, as they do when cupsfilter was used with
>> any file I threw at it. Not much use in my testing the Ghostscript
>> command in that situation. The OP's experiences might be different, of
>> course.
>
> I did all this. On http://demo.accelibreinfo.eu/error_log you have my
> newest log, job 74 and 75. Still not printing.
 Are we to assume you did the following?

 1. Set up a queue as shown above. (There is no output because it goes to
/dev/null).
>>> With lpadmin, yes. And in Printers - Queue - Default options.
>>>
>>>
 2. Print to it with 'lp -d /etc/services'.
>>> I tried to print a test page. If I do lp -d /etc/services, I get "no
>>> such file or dir". If I add a pdf file (lp -d /etc/services file.pdf" or
>>> "lp file.pdf -d /etc/services", I get a similar error message.
>> Sometimes a respondent makes an error or a there is typo. Consulting the
>> lp manual might have helped you to sort it yourself.
>>
>>  lp -d 1750 /etc/services
> Ok thank. Sorry I did not look at the man as I am very confused with the
> complexity of Cups commands as the problem requires advanced commands.
> So in the global stream, I lack of knowledge sometimes. :) Anyway, the
> command gives the same result. Log is up-to-date on
> http://demo.accelibreinfo.eu/error_log
>
>
>
 3. Examine the error_log. Four filters are used. Do any of them fail?
>>> Logs dont seem to say another error than the initial mail I posted,
>>> "COuld not find default_gray.icc", and "Cannot find device profile".
>>> Just some lines later however, I have "gstoraster filter stopped" with
>>> status 1. So I would say this filter fails.
>>>
> I add also that I think indeed it is a ghostscript problem, but changing
> the commandline as suggested in the bug report is impossible for me as I
> dont know how I could set cups to change the commandline it sends.
 Your three logs show gstoraster stopped, so spliX has no input from it
 to render. We can test the ghostscript command without doing anything to
 cups. The command is in your logs.

 gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE \
-dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr \
-sOutputFile=%stdout \   <- Replace %stdout with out.ras.
>>> Not sure I understood: I did: -sOutputFile=out.ras \
>> That's ok.
>>
-sDEVICE=cups -r600x600 -dMediaPosition=1 -dDEVICEWIDTHPOINTS=595 \
-dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=1 -dcupsColorOrder=0 \
-dcupsColorSpace=3 -dcupsCompression=17 -scupsPageSizeName=A4 \
-I/usr/share/cups/fonts -c \
input.pdf

 I have removed the -c switch and its argument because the argument is
 interpreted as PostScript code and we are not inputting PostScript.

 I have also split the command to use short, readable lines; the "\"s
 have to be omitted when it is put on a single line.

 Before running the gs command we need an input.pdf which has been
 processed by cups. Do this:

 cupsfilter -p /etc/cups/ppd/Samsung.ppd -m application/vnd.cups-pdf 
 /etc/services > input.pdf
>>> o

Re: Printing impossible

[MENGUAL Jean-Philippe]

Logo Hypra  JEAN-PHILIPPE MENGUAL
DIRECTEUR TECHNIQUE ET QUALITÉ
102, rue des poissonniers, 75018, Paris
Tel : +331 84 73 06 61  Mob : +336 76 34 93 37

jpmeng...@hypra.fr 
www.hypra.fr 
Facebook Hypra  Twitter Hypra
 Linkedin Jean-Philippe




Le 26/03/2018 à 01:17, Brian a écrit :
> On Sun 25 Mar 2018 at 22:51:25 +0200, MENGUAL Jean-Philippe wrote:
> 
>> Le 25/03/2018 à 19:05, Brian a écrit :
>>> On Sun 25 Mar 2018 at 11:29:38 +0200, MENGUAL Jean-Philippe wrote:
>>>
> I'll add that I set up a queue with
>
>   lpadmin - p 1750 -v file:/dev/null -E -m 
> drv:///splix-samsung.drv/ml1750.ppd
>
> and printed the test page from the CUPS web interface. All filters
> completed without any errors, as they do when cupsfilter was used with
> any file I threw at it. Not much use in my testing the Ghostscript
> command in that situation. The OP's experiences might be different, of
> course.


 I did all this. On http://demo.accelibreinfo.eu/error_log you have my
 newest log, job 74 and 75. Still not printing.
>>>
>>> Are we to assume you did the following?
>>>
>>> 1. Set up a queue as shown above. (There is no output because it goes to
>>>/dev/null).
>>
>> With lpadmin, yes. And in Printers - Queue - Default options.
>>
>>
>>> 2. Print to it with 'lp -d /etc/services'.
>>
>> I tried to print a test page. If I do lp -d /etc/services, I get "no
>> such file or dir". If I add a pdf file (lp -d /etc/services file.pdf" or
>> "lp file.pdf -d /etc/services", I get a similar error message.
> 
> Sometimes a respondent makes an error or a there is typo. Consulting the
> lp manual might have helped you to sort it yourself.
> 
>  lp -d 1750 /etc/services

Ok thank. Sorry I did not look at the man as I am very confused with the
complexity of Cups commands as the problem requires advanced commands.
So in the global stream, I lack of knowledge sometimes. :) Anyway, the
command gives the same result. Log is up-to-date on
http://demo.accelibreinfo.eu/error_log



>>> 3. Examine the error_log. Four filters are used. Do any of them fail?
>>
>> Logs dont seem to say another error than the initial mail I posted,
>> "COuld not find default_gray.icc", and "Cannot find device profile".
>> Just some lines later however, I have "gstoraster filter stopped" with
>> status 1. So I would say this filter fails.
>>
 I add also that I think indeed it is a ghostscript problem, but changing
 the commandline as suggested in the bug report is impossible for me as I
 dont know how I could set cups to change the commandline it sends.
>>>
>>> Your three logs show gstoraster stopped, so spliX has no input from it
>>> to render. We can test the ghostscript command without doing anything to
>>> cups. The command is in your logs.
>>>
>>> gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE \
>>>-dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr \
>>>-sOutputFile=%stdout \   <- Replace %stdout with out.ras.
>>
>> Not sure I understood: I did: -sOutputFile=out.ras \
> 
> That's ok.
> 
>>>-sDEVICE=cups -r600x600 -dMediaPosition=1 -dDEVICEWIDTHPOINTS=595 \
>>>-dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=1 -dcupsColorOrder=0 \
>>>-dcupsColorSpace=3 -dcupsCompression=17 -scupsPageSizeName=A4 \
>>>-I/usr/share/cups/fonts -c \
>>>input.pdf
>>>
>>> I have removed the -c switch and its argument because the argument is
>>> interpreted as PostScript code and we are not inputting PostScript.
>>>
>>> I have also split the command to use short, readable lines; the "\"s
>>> have to be omitted when it is put on a single line.
>>>
>>> Before running the gs command we need an input.pdf which has been
>>> processed by cups. Do this:
>>>
>>> cupsfilter -p /etc/cups/ppd/Samsung.ppd -m application/vnd.cups-pdf 
>>> /etc/services > input.pdf
>>
>> ok many thanks. input.pdf processing (first command) gives:
>>   ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
>> default_gray.icc
>> | ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find
>> device profile
>> Unrecoverable error: rangecheck in .putdeviceprops
>> Operand stack:
>> true
>>
>>> Also use any other PDF on your machine as input.pdf.
>>
>> I get:
>>  ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
>> default_gray.icc
>> | ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find
>> device profile
>> Unrecoverable error: rangecheck in .putdeviceprops
>> Operand stack:
>> true
>>
>>
>> That is wh I reported to ghoscript before asking here.
> 
> And upstream at https://bugs.ghostscript.com/show_bug.cgi?id=695873 said:
> 
>  > The only way to tell for sure would be to try removing each
>  > option until the problem goes away. You can do *that* from
>  > the command shell yourself.
>

Re: Printing impossible

[Brian]

On Sun 25 Mar 2018 at 22:51:25 +0200, MENGUAL Jean-Philippe wrote:

> Le 25/03/2018 à 19:05, Brian a écrit :
> > On Sun 25 Mar 2018 at 11:29:38 +0200, MENGUAL Jean-Philippe wrote:
> > 
> >>> I'll add that I set up a queue with
> >>>
> >>>   lpadmin - p 1750 -v file:/dev/null -E -m 
> >>> drv:///splix-samsung.drv/ml1750.ppd
> >>>
> >>> and printed the test page from the CUPS web interface. All filters
> >>> completed without any errors, as they do when cupsfilter was used with
> >>> any file I threw at it. Not much use in my testing the Ghostscript
> >>> command in that situation. The OP's experiences might be different, of
> >>> course.
> >>
> >>
> >> I did all this. On http://demo.accelibreinfo.eu/error_log you have my
> >> newest log, job 74 and 75. Still not printing.
> > 
> > Are we to assume you did the following?
> > 
> > 1. Set up a queue as shown above. (There is no output because it goes to
> >/dev/null).
> 
> With lpadmin, yes. And in Printers - Queue - Default options.
> 
> 
> > 2. Print to it with 'lp -d /etc/services'.
> 
> I tried to print a test page. If I do lp -d /etc/services, I get "no
> such file or dir". If I add a pdf file (lp -d /etc/services file.pdf" or
> "lp file.pdf -d /etc/services", I get a similar error message.

Sometimes a respondent makes an error or a there is typo. Consulting the
lp manual might have helped you to sort it yourself.

 lp -d 1750 /etc/services

> > 3. Examine the error_log. Four filters are used. Do any of them fail?
> 
> Logs dont seem to say another error than the initial mail I posted,
> "COuld not find default_gray.icc", and "Cannot find device profile".
> Just some lines later however, I have "gstoraster filter stopped" with
> status 1. So I would say this filter fails.
> 
> >> I add also that I think indeed it is a ghostscript problem, but changing
> >> the commandline as suggested in the bug report is impossible for me as I
> >> dont know how I could set cups to change the commandline it sends.
> > 
> > Your three logs show gstoraster stopped, so spliX has no input from it
> > to render. We can test the ghostscript command without doing anything to
> > cups. The command is in your logs.
> > 
> > gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE \
> >-dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr \
> >-sOutputFile=%stdout \   <- Replace %stdout with out.ras.
> 
> Not sure I understood: I did: -sOutputFile=out.ras \

That's ok.

> >-sDEVICE=cups -r600x600 -dMediaPosition=1 -dDEVICEWIDTHPOINTS=595 \
> >-dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=1 -dcupsColorOrder=0 \
> >-dcupsColorSpace=3 -dcupsCompression=17 -scupsPageSizeName=A4 \
> >-I/usr/share/cups/fonts -c \
> >input.pdf
> > 
> > I have removed the -c switch and its argument because the argument is
> > interpreted as PostScript code and we are not inputting PostScript.
> > 
> > I have also split the command to use short, readable lines; the "\"s
> > have to be omitted when it is put on a single line.
> > 
> > Before running the gs command we need an input.pdf which has been
> > processed by cups. Do this:
> > 
> > cupsfilter -p /etc/cups/ppd/Samsung.ppd -m application/vnd.cups-pdf 
> > /etc/services > input.pdf
> 
> ok many thanks. input.pdf processing (first command) gives:
>   ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
> default_gray.icc
> | ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find
> device profile
> Unrecoverable error: rangecheck in .putdeviceprops
> Operand stack:
> true
> 
> > Also use any other PDF on your machine as input.pdf.
> 
> I get:
>  ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
> default_gray.icc
> | ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find
> device profile
> Unrecoverable error: rangecheck in .putdeviceprops
> Operand stack:
> true
> 
> 
> That is wh I reported to ghoscript before asking here.

And upstream at https://bugs.ghostscript.com/show_bug.cgi?id=695873 said:

 > The only way to tell for sure would be to try removing each
 > option until the problem goes away. You can do *that* from
 > the command shell yourself.

You have the command. Remove options one by one and report back.

-- 
Brian.

Re: Printing impossible

[MENGUAL Jean-Philippe]

Logo Hypra  JEAN-PHILIPPE MENGUAL
DIRECTEUR TECHNIQUE ET QUALITÉ
102, rue des poissonniers, 75018, Paris
Tel : +331 84 73 06 61  Mob : +336 76 34 93 37

jpmeng...@hypra.fr 
www.hypra.fr 
Facebook Hypra  Twitter Hypra
 Linkedin Jean-Philippe




Le 25/03/2018 à 19:05, Brian a écrit :
> On Sun 25 Mar 2018 at 11:29:38 +0200, MENGUAL Jean-Philippe wrote:
> 
>>> I'll add that I set up a queue with
>>>
>>>   lpadmin - p 1750 -v file:/dev/null -E -m 
>>> drv:///splix-samsung.drv/ml1750.ppd
>>>
>>> and printed the test page from the CUPS web interface. All filters
>>> completed without any errors, as they do when cupsfilter was used with
>>> any file I threw at it. Not much use in my testing the Ghostscript
>>> command in that situation. The OP's experiences might be different, of
>>> course.
>>
>>
>> I did all this. On http://demo.accelibreinfo.eu/error_log you have my
>> newest log, job 74 and 75. Still not printing.
> 
> Are we to assume you did the following?
> 
> 1. Set up a queue as shown above. (There is no output because it goes to
>/dev/null).

With lpadmin, yes. And in Printers - Queue - Default options.


> 2. Print to it with 'lp -d /etc/services'.

I tried to print a test page. If I do lp -d /etc/services, I get "no
such file or dir". If I add a pdf file (lp -d /etc/services file.pdf" or
"lp file.pdf -d /etc/services", I get a similar error message.


> 3. Examine the error_log. Four filters are used. Do any of them fail?

Logs dont seem to say another error than the initial mail I posted,
"COuld not find default_gray.icc", and "Cannot find device profile".
Just some lines later however, I have "gstoraster filter stopped" with
status 1. So I would say this filter fails.

>> I add also that I think indeed it is a ghostscript problem, but changing
>> the commandline as suggested in the bug report is impossible for me as I
>> dont know how I could set cups to change the commandline it sends.
> 
> Your three logs show gstoraster stopped, so spliX has no input from it
> to render. We can test the ghostscript command without doing anything to
> cups. The command is in your logs.
> 
> gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE \
>-dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr \
>-sOutputFile=%stdout \   <- Replace %stdout with out.ras.

Not sure I understood: I did: -sOutputFile=out.ras \

>-sDEVICE=cups -r600x600 -dMediaPosition=1 -dDEVICEWIDTHPOINTS=595 \
>-dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=1 -dcupsColorOrder=0 \
>-dcupsColorSpace=3 -dcupsCompression=17 -scupsPageSizeName=A4 \
>-I/usr/share/cups/fonts -c \
>input.pdf
> 
> I have removed the -c switch and its argument because the argument is
> interpreted as PostScript code and we are not inputting PostScript.
> 
> I have also split the command to use short, readable lines; the "\"s
> have to be omitted when it is put on a single line.
> 
> Before running the gs command we need an input.pdf which has been
> processed by cups. Do this:
> 
> cupsfilter -p /etc/cups/ppd/Samsung.ppd -m application/vnd.cups-pdf 
> /etc/services > input.pdf

ok many thanks. input.pdf processing (first command) gives:
  ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
default_gray.icc
| ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find
device profile
Unrecoverable error: rangecheck in .putdeviceprops
Operand stack:
true

> Also use any other PDF on your machine as input.pdf.

I get:
 ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
default_gray.icc
| ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find
device profile
Unrecoverable error: rangecheck in .putdeviceprops
Operand stack:
true


That is wh I reported to ghoscript before asking here.

> 'file out.ras' will identify out.ras as CUPS raster


oh ok  I understand better.

Best regards and many thanks for your help for this complex problem.

Re: Printing impossible

[Brian]

On Sun 25 Mar 2018 at 11:29:38 +0200, MENGUAL Jean-Philippe wrote:

> > I'll add that I set up a queue with
> > 
> >   lpadmin - p 1750 -v file:/dev/null -E -m 
> > drv:///splix-samsung.drv/ml1750.ppd
> > 
> > and printed the test page from the CUPS web interface. All filters
> > completed without any errors, as they do when cupsfilter was used with
> > any file I threw at it. Not much use in my testing the Ghostscript
> > command in that situation. The OP's experiences might be different, of
> > course.
> 
> 
> I did all this. On http://demo.accelibreinfo.eu/error_log you have my
> newest log, job 74 and 75. Still not printing.

Are we to assume you did the following?

1. Set up a queue as shown above. (There is no output because it goes to
   /dev/null).

2. Print to it with 'lp -d /etc/services'.

3. Examine the error_log. Four filters are used. Do any of them fail?

> I add also that I think indeed it is a ghostscript problem, but changing
> the commandline as suggested in the bug report is impossible for me as I
> dont know how I could set cups to change the commandline it sends.

Your three logs show gstoraster stopped, so spliX has no input from it
to render. We can test the ghostscript command without doing anything to
cups. The command is in your logs.

gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE \
   -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr \
   -sOutputFile=%stdout \   <- Replace %stdout with out.ras.
   -sDEVICE=cups -r600x600 -dMediaPosition=1 -dDEVICEWIDTHPOINTS=595 \
   -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=1 -dcupsColorOrder=0 \
   -dcupsColorSpace=3 -dcupsCompression=17 -scupsPageSizeName=A4 \
   -I/usr/share/cups/fonts -c \
   input.pdf

I have removed the -c switch and its argument because the argument is
interpreted as PostScript code and we are not inputting PostScript.

I have also split the command to use short, readable lines; the "\"s
have to be omitted when it is put on a single line.

Before running the gs command we need an input.pdf which has been
processed by cups. Do this:

cupsfilter -p /etc/cups/ppd/Samsung.ppd -m application/vnd.cups-pdf 
/etc/services > input.pdf

Also use any other PDF on your machine as input.pdf.

'file out.ras' will identify out.ras as CUPS raster.

-- 
Brian.

Re: Printing impossible

[MENGUAL Jean-Philippe]

> 
> I'll add that I set up a queue with
> 
>   lpadmin - p 1750 -v file:/dev/null -E -m drv:///splix-samsung.drv/ml1750.ppd
> 
> and printed the test page from the CUPS web interface. All filters
> completed without any errors, as they do when cupsfilter was used with
> any file I threw at it. Not much use in my testing the Ghostscript
> command in that situation. The OP's experiences might be different, of
> course.


I did all this. On http://demo.accelibreinfo.eu/error_log you have my
newest log, job 74 and 75. Still not printing.

I add also that I think indeed it is a ghostscript problem, but changing
the commandline as suggested in the bug report is impossible for me as I
dont know how I could set cups to change the commandline it sends.

Thanks for any further help.

Best regards

Re: Printing impossible

[MENGUAL Jean-Philippe]

>>>  Printers -> Queue -> Administration -> Set Default Options

SRT is set to normal and the problem still appears. I disabled colord
service, and tried again the job. Not result.

>>>
>>
>> Just piping up to say he was advised by Ken Sharp (as an initial
>> experimental move) to remove "setpagedevice" from the gs command line
>> here (after having metooed a bug that turned out being a different one
>> from the one from which he suffers):
>>
>> https://bugs.ghostscript.com/show_bug.cgi?id=695873
>>
>> Sorry if this is merely a distraction.

Sorry I han not mentioned this as I was said it was nothing to do with
the initial bugreport, and I had not understood at all explanations.

> No need to be sorry; every little helps and it could certainly be an
> avenue for exploration. If the issue appears with a varied selection
> of files we could be looking at a defect in gstoraster's Ghostscript
> command.

So far it appears with allf iles I submitted, even in cups-filter from
your suggested command.

> 

Re: Printing impossible

[MENGUAL Jean-Philippe]

Hi guys and thanks for your feedbacks

Le 19/03/2018 à 15:53, songbird a écrit :
> MENGUAL Jean-Philippe wrote:
> ...
>> Hi,
>>
>> For some time on Buster, I no longer can print on any printer, in
>> particular my Samsung ML1750. If I check the attached log, it seems
>> however that it is not related to the printer, but rather filters. The
>> job is 71. Lines 3455 and so on are interesting I think.
>>
>> Attached file: http://demo.accelibreinfo.eu/error_log
>>
>> Would you have an idea about the pb? What could I do to fix it?
>> Many thanks for help
> 
>   first thing i would try is to completely purge/remove
> cups and reinstall to make sure i had all the required
> parts.  then i would set up the printer and try a

I unistalled via tasksel, then apt remove --purge all cups packages and
printer-* packages. However I need to say that the configuration wan not
purged, then I found my printer immediately after I re-installed cups.

> test page.

I did after I removed and reinstalled the printer. No result.

> 
>   since you didn't say what you had tried already...

I had not tried as logs seemed to show another problem.

Regards

> 
>   songbird
> 
>