[Gimp-print-devel] 5.3 futures and 5.2.13

[Robert Krawitz]

I wanted to go back over the list of things to do for 5.3/6.0, to see
what else I was thinking about. Rather to my surprise, it looks like
all of these are actually done -- the first in the units-branch for
the next more-than-point release, and the others are already in the
mainline. I didn't find any replies to this message.

Looking back through much older wish lists (e. g. the 5.0 release
plan), I also don't see a lot more that's potentially incompatible
that we might want to add. I can see other compatible things we may
want to do, such as an ESC/P-R driver for newer Epson printers (at
least the non-photo ones), but those don't need to be in 5.3 per se.

Solomon, I know you want to revamp the paper API; this would be the
time to do so.

As far as 5.2.13, we have the bug fix for A4 paper, some other fixes
for the Canon driver, non-interactive GIMP plugin, and otherwise the
usual additions for new printers.

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.

Anything else?

------- Start of forwarded message -------
Date: Sat, 19 Mar 2016 15:31:18 -0400
From: Robert Krawitz <***@alum.mit.edu>
To: "Gutenprint \(formerly Gimp-Print\) printer driver development"
<gimp-print-***@lists.sourceforge.net>
CC: gimp-print-***@lists.sourceforge.net
In-reply-to: <***@shaftnet.org> (***@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 -------

[Solomon Peachy]

Post by Robert Krawitz
Solomon, I know you want to revamp the paper API; this would be the
time to do so.

Yeah, I agree this is the time to do it. I have a bit of time this
evening; I'll rebase my old patches and see what I had left to do, then
toss another RFC round to the list.

The problem with the paper API is that it's decoupled from any specific
printer -- every size used by every printer needs to be statically
defined in the xml -- and given that the printer driver might alter the
actual dimensions reported for a given name anyway, at best it's just a
nominal page size anyway.

So, I see two options:

* Take the existing paper API private and pare it down (My preference)
We should add a few extra properties to stp_vars so that applications
won't lose any info they can get to right now -- descriptive stuff
like the 'text' and 'comment' fields, for example.
* Rejigger the paper API so that it's context-aware, usable only after
you've selected a printer, and only displaying sizes a given printer
supports.

I only know of one out-of-tree user of the paper API, photoprint. It was
essentially abandoned in 2012, and that only uses
stp_get_papersize_by_name() to look up page dimensions, falling back to
to stp_get_media_size for custom or other non-matching sizes.

Post by Robert Krawitz
As far as 5.2.13, we have the bug fix for A4 paper, some other fixes
for the Canon driver, non-interactive GIMP plugin, and otherwise the
usual additions for new printers.

There's another GIMP plugin patch in the tracker, but I don't have
anything pending beyond another backend resync to catch up with a
handful of bugfixes.

Post by Robert Krawitz
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.

It would probably be worth doing a pass over the README too, in case
anything in there is out of date or is otherwise only documented in the
NEWS file...

- Solomon

[Robert Krawitz]

Post by Solomon Peachy

Post by Robert Krawitz
Solomon, I know you want to revamp the paper API; this would be the
time to do so.

Yeah, I agree this is the time to do it. I have a bit of time this
evening; I'll rebase my old patches and see what I had left to do, then
toss another RFC round to the list.
The problem with the paper API is that it's decoupled from any specific
printer -- every size used by every printer needs to be statically
defined in the xml -- and given that the printer driver might alter the
actual dimensions reported for a given name anyway, at best it's just a
nominal page size anyway.

Agreed, that's not good.

Post by Solomon Peachy
* Take the existing paper API private and pare it down (My preference)
We should add a few extra properties to stp_vars so that applications
won't lose any info they can get to right now -- descriptive stuff
like the 'text' and 'comment' fields, for example.
* Rejigger the paper API so that it's context-aware, usable only after
you've selected a printer, and only displaying sizes a given printer
supports.

Every other property is this way; it's only meaningful in the context
of a particular printer.

As I see it:

* stp_known_papersizes() would go away. It's currently used (within
tree) only by the family drivers themselves to enumerate paper
sizes, and by print-papers.c itself for similar purposes.

* stp_get_papersize_by_index is used in basically the same way, and
should probably go away too.

* stp_get_papersize_by_foobar obviously needs to take a const
stp_vars_t* as an argument (the first argument by standard
convention).

- stp_get_papersize_by_size_exact isn't used at all.

- stp_get_papersize_by_size is used by some of the drivers (Canon,
Lexmark, and PCL) for the reasons we've been talking about
lately. If the driver supplies the paper sizes, the rationale for
this goes away.

- stp_get_papersize_by_name is used by genppd, rastertoprinter, and
libgutenprintui2. Calls to it are quite isolated and hardly
pervasive.

* stp_default_media_size isn't a property of the paper; it's a
property of the printer in its current configuration.
Interestingly, it's only used within the core itself.

So it looks like you have pretty free rein here.

Post by Solomon Peachy
I only know of one out-of-tree user of the paper API, photoprint. It was
essentially abandoned in 2012, and that only uses
stp_get_papersize_by_name() to look up page dimensions, falling back to
to stp_get_media_size for custom or other non-matching sizes.

I'm not too worried about that. We're already breaking the API with
the floating point units stuff, so we might as well do it right.

Post by Solomon Peachy

Post by Robert Krawitz
As far as 5.2.13, we have the bug fix for A4 paper, some other fixes
for the Canon driver, non-interactive GIMP plugin, and otherwise the
usual additions for new printers.

There's another GIMP plugin patch in the tracker, but I don't have
anything pending beyond another backend resync to catch up with a
handful of bugfixes.

Yes, that reminds me. I need to look at it.

Post by Solomon Peachy

Post by Robert Krawitz
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.

It would probably be worth doing a pass over the README too, in case
anything in there is out of date or is otherwise only documented in the
NEWS file...

[Solomon Peachy]

Post by Robert Krawitz
* stp_known_papersizes() would go away. It's currently used (within
tree) only by the family drivers themselves to enumerate paper
sizes, and by print-papers.c itself for similar purposes.
* stp_get_papersize_by_index is used in basically the same way, and
should probably go away too.

We'll still need something like it for internal/private use, as
papers.xml is still useful for the printer families that use
user-supplied paper.

Post by Robert Krawitz
* stp_get_papersize_by_foobar obviously needs to take a const
stp_vars_t* as an argument (the first argument by standard
convention).

In the end, a new variation of stp_get_papersize_by_name() is probably
all that is needed externally.

Post by Robert Krawitz
- stp_get_papersize_by_size_exact isn't used at all.

Already nuked. :)

Post by Robert Krawitz
- stp_get_papersize_by_size is used by some of the drivers (Canon,
Lexmark, and PCL) for the reasons we've been talking about
lately. If the driver supplies the paper sizes, the rationale for
this goes away.

I've already managed to nuke all of its users, except for one that's
#ifdef'd out but is intended to look up margins.

Do you think looking up papers by size is going to be of any use
externally?

Post by Robert Krawitz
- stp_get_papersize_by_name is used by genppd, rastertoprinter, and
libgutenprintui2. Calls to it are quite isolated and hardly
pervasive.

I've already nuked all non-driver uses -- but the remaining users
use it to look up the paper margins from the xml, so that probably needs
to stay.

I've pushed my code now, to 'papers-branch'

- Solomon

[Steve Letter]

I have another Datamax O'Neil printer I would like to add (customer request) but I am too busy this week and the first part of next.  I should be able to complete it by the end of next week though.
 Steve Letter You're never to old to learn something stupid.  -- unknown

From: Robert Krawitz <***@alum.mit.edu>
To: gimp-print-***@lists.sourceforge.net
Sent: Sunday, March 26, 2017 4:49 PM
Subject: [Gimp-print-devel] 5.3 futures and 5.2.13

I wanted to go back over the list of things to do for 5.3/6.0, to see
what else I was thinking about.  Rather to my surprise, it looks like
all of these are actually done -- the first in the units-branch for
the next more-than-point release, and the others are already in the
mainline.  I didn't find any replies to this message.

Looking back through much older wish lists (e. g. the 5.0 release
plan), I also don't see a lot more that's potentially incompatible
that we might want to add.  I can see other compatible things we may
want to do, such as an ESC/P-R driver for newer Epson printers (at
least the non-photo ones), but those don't need to be in 5.3 per se.

Solomon, I know you want to revamp the paper API; this would be the
time to do so.

As far as 5.2.13, we have the bug fix for A4 paper, some other fixes
for the Canon driver, non-interactive GIMP plugin, and otherwise the
usual additions for new printers.

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.

Anything else?

------- Start of forwarded message -------
Date: Sat, 19 Mar 2016 15:31:18 -0400
From: Robert Krawitz <***@alum.mit.edu>
To: "Gutenprint \(formerly Gimp-Print\) printer driver development"
    <gimp-print-***@lists.sourceforge.net>
CC: gimp-print-***@lists.sourceforge.net
In-reply-to: <***@shaftnet.org> (***@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]

Post by Steve Letter
I have another Datamax O'Neil printer I would like to add (customer
request) but I am too busy this week and the first part of next. I
should be able to complete it by the end of next week though.

OK. We'll do at least one pre-release for 5.2.13, maybe even later
this week, and you can add it either before or after that. There's no
hurry for this for 5.3/6.0; I'm merging the branch up regularly.

[Gernot Hassenpflug]

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

/../
Hello Robert,

Post by Robert Krawitz
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.

Post by Robert Krawitz
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

Post by Robert Krawitz
------- Start of forwarded message -------
Date: Sat, 19 Mar 2016 15:31:18 -0400
To: "Gutenprint \(formerly Gimp-Print\) printer driver development"
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
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 -------
--
*** 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
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel