[Gimp-print-devel] [gimp-print:bugs] #689 Pixma MG5740 resolution and duplex printing issue

[Gernot Hassenpflug]

On Sun, Mar 5, 2017 at 12:03 AM, Robert Krawitz <***@alum.mit.edu> wrote:

Hello all,

Quick progress report and question about the Orientation parameter.

Actually, there is a page number facility available for duplex. Look at
escp2_do_print() in print-escp2.c. It's passed in by
rastertoprinter.c, at line 1365.
Also see escp2_print, escp2_job_start, and escp2_job_end. Gutenprint
has two job modes, "job" and "page". Page mode is used for apps like
the GIMP plugin, that just print one page; job mode is used by the
CUPS filter that print multiple pages per job.

I have worked on improving the duplex implementation in the Canon driver.
The Esc (u and Esc (s commands now behave as they should, save for the
limitation that the Esc (s command is also output on the last page
(unlike in the Windows driver).

I found that I can add support for printing orientation as well, as
the Esc (v and Esc (P command parameters change depending on the
rotation (0, 90, 180, or 270 degrees).
However, I could not manage to pass the CUPS Orientation parameters to
gutenprint. I am not sure if rastertoprinter.c needs some change. I
added the code I thought was necessary, to get the parameter into the
PPDs also (this seems to be the case).
Passing "-o landscape" or "-o orientation-request=3" (or 4,5,6) from
lp or lpr shows only something like this in the debug log:

D [12/Mar/2017:00:12:03 +0900] [Job 987] Gutenprint: CUPS option 6
landscape = true
or
D [12/Mar/2017:00:15:08 +0900] [Job 988] Gutenprint: CUPS option 7
orientation-request = 5

but how this is supposed to be passed to gutenprint in the form of the
PPD parameter names is not clear to me. Any help appreciated.

Regards,
Gernot Hassenpflug

------- Start of forwarded message -------
Content-Type: multipart/related;
boundary="===============4467390184386401729=="
Subject: [gimp-print:bugs] #689 Pixma MG5740 resolution and duplex printing issue
Date: Sat, 04 Mar 2017 06:36:42 +0000
Hello Jurgen,
I checked the current canon-printers.h definition and my original test printjobs from Windows. The definition is correct, as are the modes in canon-modes.h. There is no 300x300 resolution mode, the draft one in Windows also uses 600x600 but with a quality setting of 1 which is lower than the other 600x600 modes. Probably this printer's firmware and/or printhead does not have 300x300 capability.
I checked the defined margins against the Canon PPD and they are fine also.
Regarding the duplex, there is an interesting aspect. This printer has a command "Esc (s 0x0" sent only for duplex on each page except the last one (I think). This is coded but not active at the moment. So lack of this could be the cause for duplex margin problems.
For implementation, the troublesome part is that in gutenprint there is at the moment no page counter, so the command would be sent for every page if activated.
If you can compile gutenprint, you could test this, or I could send you a multipage text-only printjob for you to send to the printer with the "-o raw" command.
--
*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Robert Krawitz]

Post by Gernot Hassenpflug
Hello all,
Quick progress report and question about the Orientation parameter.

Actually, there is a page number facility available for duplex. Look at
escp2_do_print() in print-escp2.c. It's passed in by
rastertoprinter.c, at line 1365.
Also see escp2_print, escp2_job_start, and escp2_job_end. Gutenprint
has two job modes, "job" and "page". Page mode is used for apps like
the GIMP plugin, that just print one page; job mode is used by the
CUPS filter that print multiple pages per job.

I have worked on improving the duplex implementation in the Canon driver.
The Esc (u and Esc (s commands now behave as they should, save for the
limitation that the Esc (s command is also output on the last page
(unlike in the Windows driver).
I found that I can add support for printing orientation as well, as
the Esc (v and Esc (P command parameters change depending on the
rotation (0, 90, 180, or 270 degrees).

What exactly is this needed for? CUPS handles the orientation
internally, by rotating it itself and giving it to the filter without
the filter ever seeing the rotation. Does this affect paper handling
in some way?

[Gernot Hassenpflug]

Hello Robert,
/../

Post by Robert Krawitz

Post by Gernot Hassenpflug
I have worked on improving the duplex implementation in the Canon driver.
The Esc (u and Esc (s commands now behave as they should, save for the
limitation that the Esc (s command is also output on the last page
(unlike in the Windows driver).
I found that I can add support for printing orientation as well, as
the Esc (v and Esc (P command parameters change depending on the
rotation (0, 90, 180, or 270 degrees).

What exactly is this needed for? CUPS handles the orientation
internally, by rotating it itself and giving it to the filter without
the filter ever seeing the rotation. Does this affect paper handling
in some way?

I cannot test that myself, as I don't have a printer with such
capabilities (MP450 only).
But yes, I believe it has to do with the paper handling, and perhaps
the algorithms to do the actual printing.

Regards,
Gernot

[Robert Krawitz]

Post by Gernot Hassenpflug
Hello Robert,
/../

Post by Robert Krawitz

Post by Gernot Hassenpflug
I have worked on improving the duplex implementation in the Canon driver.
The Esc (u and Esc (s commands now behave as they should, save for the
limitation that the Esc (s command is also output on the last page
(unlike in the Windows driver).
I found that I can add support for printing orientation as well, as
the Esc (v and Esc (P command parameters change depending on the
rotation (0, 90, 180, or 270 degrees).

What exactly is this needed for? CUPS handles the orientation
internally, by rotating it itself and giving it to the filter without
the filter ever seeing the rotation. Does this affect paper handling
in some way?

I cannot test that myself, as I don't have a printer with such
capabilities (MP450 only).
But yes, I believe it has to do with the paper handling, and perhaps
the algorithms to do the actual printing.

Without knowing what the printer does differently with this knowledge,
it's hard to know what to say about it.

[Gernot Hassenpflug]

Post by Robert Krawitz

Post by Gernot Hassenpflug
Hello Robert,
/../

Post by Robert Krawitz

Post by Gernot Hassenpflug
I have worked on improving the duplex implementation in the Canon driver.
The Esc (u and Esc (s commands now behave as they should, save for the
limitation that the Esc (s command is also output on the last page
(unlike in the Windows driver).
I found that I can add support for printing orientation as well, as
the Esc (v and Esc (P command parameters change depending on the
rotation (0, 90, 180, or 270 degrees).

What exactly is this needed for? CUPS handles the orientation
internally, by rotating it itself and giving it to the filter without
the filter ever seeing the rotation. Does this affect paper handling
in some way?

I cannot test that myself, as I don't have a printer with such
capabilities (MP450 only).
But yes, I believe it has to do with the paper handling, and perhaps
the algorithms to do the actual printing.

Without knowing what the printer does differently with this knowledge,
it's hard to know what to say about it.

Yes, it would need testing, but then almost every reverse-engineered
command has been put in as experimental without knowing exactly what
it does. My aim is to avoid bugs that printers do not print because
commands are incorrectly implemented, and I thought this would be an
easy and convenient addition.
I have a iP100, but since I cannot even figure out how to parse the
ink information I cannot use this to test paper handling.
I'll leave the code support in as it is, but it will remain untestable
for now unless hardcoded and compiled. I am guessing genppd.c and
rastertoprinter.c need changing too.

Regards,
Gernot Hassenpflug

[Robert Krawitz]

Post by Gernot Hassenpflug

Post by Robert Krawitz

Post by Gernot Hassenpflug
Hello Robert,
/../

Post by Robert Krawitz

Post by Gernot Hassenpflug
I have worked on improving the duplex implementation in the Canon driver.
The Esc (u and Esc (s commands now behave as they should, save for the
limitation that the Esc (s command is also output on the last page
(unlike in the Windows driver).
I found that I can add support for printing orientation as well, as
the Esc (v and Esc (P command parameters change depending on the
rotation (0, 90, 180, or 270 degrees).

What exactly is this needed for? CUPS handles the orientation
internally, by rotating it itself and giving it to the filter without
the filter ever seeing the rotation. Does this affect paper handling
in some way?

I cannot test that myself, as I don't have a printer with such
capabilities (MP450 only).
But yes, I believe it has to do with the paper handling, and perhaps
the algorithms to do the actual printing.

Without knowing what the printer does differently with this knowledge,
it's hard to know what to say about it.

Yes, it would need testing, but then almost every reverse-engineered
command has been put in as experimental without knowing exactly what
it does. My aim is to avoid bugs that printers do not print because
commands are incorrectly implemented, and I thought this would be an
easy and convenient addition.
I have a iP100, but since I cannot even figure out how to parse the
ink information I cannot use this to test paper handling.
I'll leave the code support in as it is, but it will remain untestable
for now unless hardcoded and compiled. I am guessing genppd.c and
rastertoprinter.c need changing too.

There would need to be a really, really solid reason for genppd and
rastertoprinter to change for a printer-specific reason -- a command
that you can't test and don't understand just isn't a good case for
it.

The question is, what does this landscape setting do? Does it
actually rotate the paper 90 degrees in the act of printing? If the
user specifies a landscape paper size, you can intuit from that that
landscape mode should be used.

[Gernot Hassenpflug]

Hello Robert,
/../

Post by Robert Krawitz

Post by Gernot Hassenpflug

Post by Robert Krawitz

Post by Gernot Hassenpflug

Post by Robert Krawitz

Post by Gernot Hassenpflug
I have worked on improving the duplex implementation in the Canon driver.
The Esc (u and Esc (s commands now behave as they should, save for the
limitation that the Esc (s command is also output on the last page
(unlike in the Windows driver).
I found that I can add support for printing orientation as well, as
the Esc (v and Esc (P command parameters change depending on the
rotation (0, 90, 180, or 270 degrees).

What exactly is this needed for? CUPS handles the orientation
internally, by rotating it itself and giving it to the filter without
the filter ever seeing the rotation. Does this affect paper handling
in some way?

I cannot test that myself, as I don't have a printer with such
capabilities (MP450 only).
But yes, I believe it has to do with the paper handling, and perhaps
the algorithms to do the actual printing.

Without knowing what the printer does differently with this knowledge,
it's hard to know what to say about it.

Yes, it would need testing, but then almost every reverse-engineered
command has been put in as experimental without knowing exactly what
it does. My aim is to avoid bugs that printers do not print because
commands are incorrectly implemented, and I thought this would be an
easy and convenient addition.
I have a iP100, but since I cannot even figure out how to parse the
ink information I cannot use this to test paper handling.
I'll leave the code support in as it is, but it will remain untestable
for now unless hardcoded and compiled. I am guessing genppd.c and
rastertoprinter.c need changing too.

There would need to be a really, really solid reason for genppd and
rastertoprinter to change for a printer-specific reason -- a command
that you can't test and don't understand just isn't a good case for
it.

OK, that is a fair point.
I see the PCL driver uses orienation too, but like the Canon driver
probably the functionality is not available since the parameter is not
passed to gutenprint.

Post by Robert Krawitz
The question is, what does this landscape setting do? Does it
actually rotate the paper 90 degrees in the act of printing? If the
user specifies a landscape paper size, you can intuit from that that
landscape mode should be used.

The driver option rotates the image 90, 180, or 270 degrees, leaving
the paper as is.
In Windows there is no landscape paper selection, instead the choice
of printing portrait (default) or landscape, is offered.

The latter is a 90 degree rotation, and the commands sent to the
printer reflect this option.
In additon, there is an option for 180 degree rotation. Whether this
is active in addition to portrait or landscape choice is also
reflected in the same commands sent to the printer. 4 variations in
total.

Indeed, if in CUPS landscape papersize is chosen, that would help to
intuit. I don't know how that works, but no landscape papersizes are
available to the Canon driver, I could not figure out why that is from
the filter used to build the PPD.

Even if papersize of landscape orientation were to be chosen in CUPS,
for the printer this is not recognized in the firmware: I.e., in
Windows, regardless of the printing orientation chosen, papersize
commands use the portrait page size only, and the image area too is
the same. It would be a custom papersize (and except for small papers
probably outside the printer's width specs).

Regards,
Gernot

[Robert Krawitz]

Post by Gernot Hassenpflug

Post by Robert Krawitz
There would need to be a really, really solid reason for genppd and
rastertoprinter to change for a printer-specific reason -- a command
that you can't test and don't understand just isn't a good case for
it.

OK, that is a fair point.
I see the PCL driver uses orienation too, but like the Canon driver
probably the functionality is not available since the parameter is not
passed to gutenprint.

Post by Robert Krawitz
The question is, what does this landscape setting do? Does it
actually rotate the paper 90 degrees in the act of printing? If the
user specifies a landscape paper size, you can intuit from that that
landscape mode should be used.

The driver option rotates the image 90, 180, or 270 degrees, leaving
the paper as is.
In Windows there is no landscape paper selection, instead the choice
of printing portrait (default) or landscape, is offered.
The latter is a 90 degree rotation, and the commands sent to the
printer reflect this option.
In additon, there is an option for 180 degree rotation. Whether this
is active in addition to portrait or landscape choice is also
reflected in the same commands sent to the printer. 4 variations in
total.

It would be really useful to find out what this actually does. Does
it simply rotate the data itself? Or is there more to it?

CUPS already performs the rotation internally when landscape is
requested. This does use more memory, but other than the fact that it
could blow out the CPU cache shouldn't have much effect on processing
power required, and no effect on the amount of data transmitted.

Post by Gernot Hassenpflug
Indeed, if in CUPS landscape papersize is chosen, that would help to
intuit. I don't know how that works, but no landscape papersizes are
available to the Canon driver, I could not figure out why that is from
the filter used to build the PPD.
Even if papersize of landscape orientation were to be chosen in CUPS,
for the printer this is not recognized in the firmware: I.e., in
Windows, regardless of the printing orientation chosen, papersize
commands use the portrait page size only, and the image area too is
the same. It would be a custom papersize (and except for small papers
probably outside the printer's width specs).

It sounds like this is nothing more than a convenience for the
driver. Can you research this some more?

[Johannes Meixner]

Hello,

Post by Gernot Hassenpflug
Passing "-o landscape" or "-o orientation-request=3" (or 4,5,6)

...

Post by Gernot Hassenpflug
but how this is supposed to be passed to gutenprint in the
form of the PPD parameter names is not clear to me.

Be careful with things like "landscape", it is a snakepit!

First and formost:
--------------------------------------------------
| There is no such thing as "landscape printing" |
--------------------------------------------------
see
https://en.opensuse.org/SDB:Landscape_Printing


By the way: it is named "orientation-requested", see
https://www.cups.org/doc/options.html
and its name is plain wrong because it does not produce
a requested orientation - actually it blindly rotates
and the resulting orientation after a rotation depends
on the orientation before the rotation - what a mess!

Assume "-o landscape" or "-o orientation-requested=..."
is set, then all filtering program gets that parameter
(in argv[5]) so that all filtering program could do
what is requested.

Assume that parameter makes any filtering program
to rotate it, the final result depends on how many
filtering programs rotate it.


Finally:
--------------------------------------------------
| There is no such thing as "landscape printing" |
--------------------------------------------------
see
https://en.opensuse.org/SDB:Landscape_Printing


Kind Regards
Johannes Meixner