[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-print-devel
Subject:    Re: [Gimp-print-devel] Support for CD Tray of Canon iP7250
From:       Christian Wolf <ChristianLupus () gmx ! de>
Date:       2018-10-18 9:01:59
Message-ID: 947b2769-fb50-a092-5b88-f731d26d1589 () gmx ! de
[Download RAW message or body]

Dear Gernot,

> Basically some changes to parameters, and local changes/patches (in 
> advance of maybe pushing changes to git). Nothing like "real programming 
> skills" required, no, definitely not.
This should be of no problem.

> Yes, basically with lp or lpr, using the "-o raw" parameter.
No problem, I do not fear the command line. I only need the binary blobs 
or a way to create them.

> No problem. The main thing to realize is that this takes time, it is not 
> a quick fix issue.
At least I got my CD printed out yesterday evening. 60 disks are labeled 
without major problems. It was just a hack but this can serve as a basis 
for future modifications in the code.

> Sure, each CD tray needs its own parameters. But if the methodology is 
> working, for one tray, then I hope it only requires changes in parameter 
> values for the other trays to get them to work.
> At the moment, the methodology is not working yet, and without a tester 
> (I do not have a printer with such a functionality) there can be no 
> resolution at present.
OK, I think I get it. First let's get it running smoothly.

> OK, so you are on the right track.
> Once the right values are known, then we can try to use the new generic 
> methodology to obtain the same results.
You only need the two values in the macros in order to change the new 
methology, right?

I will have to make a test pattern in order to check exact offset on the 
disk. Normally I would do this using LaTeX/TikZ or do you have any 
better suggestion?

>     The current problem is that the border is a bit off: On the right side
>     it gets cropped by either the driver or the printer itself. I do not
>     know. I also did not try out to determine the exact region of problems.
>     Seems a thin border of around 1-2mm in the upper right edge. Could also
>     be a small error in X direction.
> 
> OK. I don't know about the exact problems that appear in printing. We 
> can always use pixma_parse to find out what the original image produced 
> by gutenprint looks like, and if that is cropped also. Lots of 
> parameters that could have an effect.
That seems to be a good idea. For now I keep a sufficient distance from 
the outer border.

> Sure. But they can be floating point 1/72 inches I presume, not sure 
> until I look more closely.
> In any case, we should try to get close results first and see if we can 
> replicate them with the new methodology.
You are right, better some results than none. But according to the code 
the left and top is calculated as int value. So no floating point precision.

OK, I think this is it for now. We wanted to make contact in order to 
get things running soon in the main framework.

-- 
Mit freundlichen Grüßen
Christian Wolf


_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[prev in list] [next in list] [prev in thread] [next in thread]