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

List:       gimp-print-devel
Subject:    Re: [Gimp-print-devel] PIXMA Pro-100 -- The Canon driver has a mind of its own
From:       Gernot Hassenpflug <aikishugyo () gmail ! com>
Date:       2018-03-05 1:16:20
Message-ID: CAN0dEZwwnhmnA6T98FE2XrDz2k_5tX2FVHatO=poSLpM_Zf_Yw () mail ! gmail ! com
[Download RAW message or body]

Hi Alex,
Resending this failed message since Sourceforge appears to be working
again (according to Twitter).
Regards,
Gernot Hassenpflug

On Fri, Mar 2, 2018 at 10:12 AM, Gernot Hassenpflug
<aikishugyo@gmail.com> wrote:
> On Fri, Mar 2, 2018 at 9:58 AM, Alex G <vazopadry@gmail.com> wrote:
>> On 02/28/2018 10:52 PM, Gernot Hassenpflug wrote:
>>>
>>> On Thu, Mar 1, 2018 at 1:30 PM, Alex G <mr.nuke.me@gmail.com> wrote:
>>>>
>>>> So who decides which drops of which ink to use? The printer or the
>>>> driver?
>>>
>>> I think it is controlled by the firrmware, and the the driver has to
>>> match these requirements. I.e, for some combination of quality, media,
>>> colour, duplex and other parameters, the firmware does a certain thing
>>> and wants certain colours in its input data.
>>
>> So it sounds like we should be able to rely on the firmware to use all inks,
>> even though we don't fully understand the meaning of all color channels.
>
> Yes.
>
> /../
>
>>> gutenprint can conceptually provide extra colours (the Epson driver
>>> provides grey, and I think green and orange also) but someone will
>>> have to create a model to convert incoming RGB data into those
>>> channels.
>>
>>
>> Isn't that something that would be better done on a paper by paper basis as
>> part of printer profiling, rather than a driver hardcode?
>
> Sure, there are 3 arrays for that, either per printer (default arrays
> used), per media and I think they can be set even by resolution mode.
> Ideally it would be per combination. However, that obviously requires
> access to the printer, and testing of all the inksets and media.
> Impossible without a printer, very time consuming and tedious also
> with a printer. Hence only present for I think 1, maybe 2 models in
> the Canon driver!
>
> /../
>
>>> To do that, you would modify the entries for the PRO-100 in
>>> canon-printers.h (general specs for commands),
>>> canon-modes.h (the definition of the individual resolution modes
>>> covering the different media and other options),
>>> canon-media.h (media definitions and their codes),
>>> canon-media-modes.h (sets of which media use which resolution modes),
>>> and add/modify inksets in canon-inks.h (these inksets are used to
>>> build the resolution modes in canon-modes.h),
>>
>> And I did most of that already [1]. However, I must have done something
>> wrong there, as I'm getting really crazy packets coming out of gutenprint,
>> such as the 23 color ESC (t.
>
> Specifying the number of colours is directly specified by the inkset
> in the resolution mode you select, so on the surface it sounds like it
> should be simple to find the offending code.
>
>>> and finally some PRO-100 specific processing as necessary in
>>> print-canon.c
>>
>> That sounds like a workaround. I've noticed an alarming number of if
>> (!strncmp("PIXMA xxx")) {}, and I've found them very distracting and
>> detracting from readability. My goal is to get full functionality without
>> adding any (new) such workarounds :)
>
> Yes, of course this is a work-around, many of which are awaiting time
> to be made into some sort of standard, while others are there because
> the code is experimental.
> As this is an open-source project, anyone is welcome to help in that
> regard, I for one would be delighted :D
>
>> https://github.com/mrnuke/krakenprint/commit/4fafa9b122aec287a468a1dadd14a788993c96f2
>
> The first step is usually to concentrate on plain media only, make
> sure the initialization command works so that a printjob is actually
> interpreted by the firmware, followed by the correct data format
> (including correct definition of the inksets and resolution modes),
> and that the various media codes are sane for plain media. For the PRO
> series there does not seem to be any particular inkset simplification
> for plain media, so working with any kind of media has more or less
> the same development overhead I imagine.
>
> Best regards,
> Gernot Hassenpflug

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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]