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

List:       gimp-print-devel
Subject:    Re: [Gimp-print-devel] 5.3 futures and 5.2.13
From:       Gernot Hassenpflug <aikishugyo () gmail ! com>
Date:       2017-03-27 13:06:25
Message-ID: CAN0dEZz+X1MVh+nGUNTQC5cg5XKa9g0sgoTbaV_DXV1KVLBiRw () mail ! gmail ! com
[Download RAW message or body]

On Mon, Mar 27, 2017 at 5:48 AM, Robert Krawitz <rlk@alum.mit.edu> wrote:

/../
Hello Robert,

> I'd also like to clean up the release notes by removing mentions of
> particular printer commands (which mean nothing to end users) and
> simply specify what the user-visible improvements are.

I've done that today.

> Anything else?

It looks like we may have to pull the Canon iP100 out, since for some
reason the print data does not conform to the expected style currently
encoded. We can read all the commands, ink definitions, etc., but not
decode the ink data for black or any other colour at the moment. It
could be that the ink definitions are not true, or else a different
data encoding is used. Very strange, since the iP90 and iP110 have no
such problems.
I have some tests I want to perform (pure black image data) after some
2 weeks of reading up on encodings, to see if I can guess something
(even to the point of checking if some variation on run-length
encoding/PackBits is used, or modified Huffman encoding, or perhaps
even delta or LZW encoding). So far we've not seen any other type of
encoding used for the print data, so I am hoping that I will discover
something fairly trivial.

Best regards,
Gernot Hassenpflug

> ------- Start of forwarded message -------
> Date: Sat, 19 Mar 2016 15:31:18 -0400
> From: Robert Krawitz <rlk@alum.mit.edu>
> To: "Gutenprint \(formerly Gimp-Print\) printer driver development"
>         <gimp-print-devel@lists.sourceforge.net>
> CC: gimp-print-devel@lists.sourceforge.net
> In-reply-to: <20160318131753.GK23307@shaftnet.org> (pizza@shaftnet.org)
> Subject: [Gimp-print-devel] Futures (was Re:  Migrating to GIT)
> Content-Type: text/plain; charset="us-ascii"
>
> So the things I remember we were talking about for the next release
> (5.3, 6.0, whatever were:
>
> 1) Changing the base unit of measurement.  Currently it's integer
>    points (1/72").  This was OK 10 or 15 years ago when printers were
>    less precise and less accurate; technology has improved a lot,
>    though, and 1/144" maximum error isn't always OK (printing to CD's
>    can be definitely off-center).  Points seem to be the standard unit
>    of measure in the printing world we could use either floating point
>    or scaling (where the base unit could be scaled).
>
>    Floating point is more convenient, of course, but also completely
>    breaks binary compatibility.  It also has the problem of
>    imprecision (rounding error) for any printer not based on 1/72".
>    It's not even exact for printers based on 1/360" or similar, since
>    1/5 can't be represented precisely in floating point.
>
>    Scaling would use a base of 1/72", but the scale factor could be
>    changed to any divisor of 1/72", and all dimensions would be
>    expressed in terms of the scaled unit.  Typically one might choose
>    the GCD of 1/72 and the printer unit; for a 300 DPI printer, that
>    would be 1/1800, so the scaling would be 25.
>
>    This would be precise (since everything would be done in integers)
>    but more complex, and I'm not sure the complexity would be worth
>    it.
>
> 2) Get rid of ijsgutenprint and foomatic.  It's far from clear whether
>    anybody is using ijsgutenprint, since CUPS seems to be pretty
>    universal in the UNIX/Linux world these days.  If nobody's using
>    ijsgutenprint, there's no point that I could see in keeping the
>    foomatic stuff around.  Either way, if we make change #1,
>    everything else would have to change, and this would be a big wad
>    to carry forward.
>
>    (The GIMP plugin would be a pretty big wad to carry forward also,
>    and we might have to make the same decision there, but I suspect it
>    has more users.)
>
> 3) I want to go through the Epson driver and ensure that the full
>    range of drop sizes is being used for all resolutions, to enable
>    people to boost the density higher at high resolutions.  That seems
>    to be causing some people some problems.  That's not an API change,
>    but it would be difficult to keep the output identical at all
>    resolutions, so in principle it's something that would best be done
>    in a major or minor release, not a point release.`
>
> Any other thoughts?
> ------- End of forwarded message -------
>
>
> --
> Robert Krawitz                                     <rlk@alum.mit.edu>
>
> ***  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
>
> ------------------------------------------------------------------------------
> 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

------------------------------------------------------------------------------
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]