[Gimp-print-devel] Dimensions -- finally!

[Robert Krawitz]

I'm finally starting work on converting dimensions to double.

I'm trying ("very" trying is a good way to put it) to convert the
various ints (and in some cases unsigneds) to stp_dimension_t, which
I'm defining as a double. It means a lot of groveling through files
and all.

[Gernot Hassenpflug]

Post by Robert Krawitz
I'm finally starting work on converting dimensions to double.
I'm trying ("very" trying is a good way to put it) to convert the
various ints (and in some cases unsigneds) to stp_dimension_t, which
I'm defining as a double. It means a lot of groveling through files
and all.

Ouch.

Is there anything we should be prepared to work on in the driver files
in preparation?

Regards,
Gernot

[Robert Krawitz]

Post by Gernot Hassenpflug

Post by Robert Krawitz
I'm finally starting work on converting dimensions to double.
I'm trying ("very" trying is a good way to put it) to convert the
various ints (and in some cases unsigneds) to stp_dimension_t, which
I'm defining as a double. It means a lot of groveling through files
and all.

Ouch.
Is there anything we should be prepared to work on in the driver files
in preparation?

Well, I got everything to compile so far (quicker than I thought, but
still a lot of work).

I've introduced two new types, stp_dimension_t and stp_resolution_t.
The former is for page dimensions; the latter is for printing
resolutions. Unfortunately, these types can't be as opaque as I'd
like, partly because C doesn't enforce type correctness across
typedefs and partly because *printf (and scanf) isn't
type-transparent.

For example of the former:

typedef double stp_dimension_t;

void
foo(stp_dimension_t f)
{
}

void
main(...)
{
double g = 0;
foo(g);
}

doesn't flag any kind of warning, because the type errors/warnings are
only emitted after type translation or whatever it's called.

The latter: *printf knows about a fixed set of types, and it's very
painful to handle that in a transparent way.

Anyone want me to push the branch to play with?

[Robert Krawitz]

Post by Robert Krawitz

Post by Gernot Hassenpflug

Post by Robert Krawitz
I'm finally starting work on converting dimensions to double.
I'm trying ("very" trying is a good way to put it) to convert the
various ints (and in some cases unsigneds) to stp_dimension_t, which
I'm defining as a double. It means a lot of groveling through files
and all.

Ouch.
Is there anything we should be prepared to work on in the driver files
in preparation?

Well, I got everything to compile so far (quicker than I thought, but
still a lot of work).

I've made a lot of progress.

I have run-testpattern-2 running; there are only two cases that
miscompare right now (it looks like something over 500, but they look
to be duplicates. There are no crash cases. The miscomparing cases
are:

* CD printing on Epson printers

* o056x344 page size on PCL printers.

The latter is because this case refused to run at all on the
integer-based code. It was resulting in a crash inside testpattern
itself on the floating point-based code due to a size (in dots which
is still of course integer) going to zero. Ensuring that the size is
at least 1 dot gets rid of that, so it runs. Since it refused to run
on the integer-based code (even though it could have, had the test
pattern generator not been buggy), I'm going to declare that
miscompare a false positive. So I'm left with just one miscomparing
case. Not bad. And the very first pass I on fixing up the library
worked correctly on apparently all but one case. Not unhappy with
that state of affairs.

I had to add an option to the test pattern generator to round floating
point dimension sizes to the lower integer (by casting to int and
back) to get rid of a lot of miscompares due to the test pattern
generator scaling to non-integer numbers of points.

I have not played with the CUPS driver yet, or the GIMP plugin, beyond
making them compile.

[Robert Krawitz]

Post by Robert Krawitz

Post by Robert Krawitz

Post by Gernot Hassenpflug

Post by Robert Krawitz
I'm finally starting work on converting dimensions to double.
I'm trying ("very" trying is a good way to put it) to convert the
various ints (and in some cases unsigneds) to stp_dimension_t, which
I'm defining as a double. It means a lot of groveling through files
and all.

Ouch.
Is there anything we should be prepared to work on in the driver files
in preparation?

Well, I got everything to compile so far (quicker than I thought, but
still a lot of work).

I've made a lot of progress.
I have run-testpattern-2 running; there are only two cases that
miscompare right now (it looks like something over 500, but they look
to be duplicates. There are no crash cases. The miscomparing cases
* CD printing on Epson printers

There are two issues here:

1) The internal computation of the positioning parameters relies on
dividing the page bottom by 2. Of course, if the page bottom
happens to be an odd number, it isn't represented correctly. I
verified this by rounding that computation down.

I think the right thing is to use the new behavior here. It may
lead to a slightly different positioning of the CD in the tray,
perhaps by half a point in some cases, but I think that's probably
OK.

2) The other issue is differences in masking caused by fully FP
computations vs. computations going back and forth between integer
and floating point. That was leading to some data differences. I
didn't see any different data from the Canon driver because of
this; not sure why.

3) When I looked more deeply into it, there were quite a few more
places in the Epson driver that had to be converted into floating
point numbers for non-integer page sizes to actually work (as
opposed to being rounded down). That means that maintainers of
other family drivers will need to look at their code

[Solomon Peachy]

Post by Robert Krawitz
3) When I looked more deeply into it, there were quite a few more
places in the Epson driver that had to be converted into floating
point numbers for non-integer page sizes to actually work (as
opposed to being rounded down). That means that maintainers of
other family drivers will need to look at their code

Just for my own sanity-checking, the intention is still to use points as
the internal unit, but allow for them to be non-integers? (I guess with
this, we can convert to whatever units we want on the outside..)

I don't think there's any floating point in the dyesub driver (or at
least nothing related to dimensions), so that's one bullet dodged.

That said, there's a lot of rounding, both up and down, to deal with
non-integer page sizes. I'm looking forward to getting rid of most of
that.

- Solomon

[Robert Krawitz]

Post by Solomon Peachy

Post by Robert Krawitz
3) When I looked more deeply into it, there were quite a few more
places in the Epson driver that had to be converted into floating
point numbers for non-integer page sizes to actually work (as
opposed to being rounded down). That means that maintainers of
other family drivers will need to look at their code

Just for my own sanity-checking, the intention is still to use points as
the internal unit, but allow for them to be non-integers? (I guess with
this, we can convert to whatever units we want on the outside..)

Yes, still using points but allowing non-integer (floating point)
values. I haven't actually tried anything with floating point paper
sizes or the like, but that's what it should do.

I still have to actually test the GIMP plugin; I got it to compile and
left it alone for the time being.

Post by Solomon Peachy
I don't think there's any floating point in the dyesub driver (or at
least nothing related to dimensions), so that's one bullet dodged.

There is now.

Post by Solomon Peachy
That said, there's a lot of rounding, both up and down, to deal with
non-integer page sizes. I'm looking forward to getting rid of most of
that.

You and Gernot are going to have to be very careful how you handle
paper sizes where the printer recognizes specific sizes. Floating
point equality comparisons are not a good way to go about things.

[Solomon Peachy]

Post by Robert Krawitz
You and Gernot are going to have to be very careful how you handle
paper sizes where the printer recognizes specific sizes. Floating
point equality comparisons are not a good way to go about things.

I believe the dyesub driver relies entirely on matching paper names
rather than dimensions, so that should be okay. But I'll have a good
look.

This new stuff will surely lead to a major API/ABI bump, so IMO it would
be a good time to rethink (if not outright eliminate) the public paper
API as well. Basically, I would finish what I started with those
patches I posted a while back.

(And that said, we should probably do a 5.2.13 point release in the
near future to fix the A4 paper and other bugs in 5.2.12)

- Solomon

[Robert Krawitz]

Post by Solomon Peachy

Post by Robert Krawitz
You and Gernot are going to have to be very careful how you handle
paper sizes where the printer recognizes specific sizes. Floating
point equality comparisons are not a good way to go about things.

I believe the dyesub driver relies entirely on matching paper names
rather than dimensions, so that should be okay. But I'll have a good
look.

That has other hazards of its own.

Post by Solomon Peachy
This new stuff will surely lead to a major API/ABI bump, so IMO it would
be a good time to rethink (if not outright eliminate) the public paper
API as well. Basically, I would finish what I started with those
patches I posted a while back.

Yes, this is a major API change. I don't know that it's enough to
call it version 6, but it certainly merits 5.3 (or 5.4, if we continue
the old even scheme).

If we're going to do that, though, we might as well decide what else
needs to change. The paper API would be a good place to start, but
remind me what changes you wanted to make?

Post by Solomon Peachy
(And that said, we should probably do a 5.2.13 point release in the
near future to fix the A4 paper and other bugs in 5.2.12)

Let's make sure we have all of those fixed; it didn't sound like
Gernot was entirely convinced.

[Gernot Hassenpflug]

Post by Robert Krawitz

Post by Solomon Peachy

Post by Robert Krawitz
You and Gernot are going to have to be very careful how you handle
paper sizes where the printer recognizes specific sizes. Floating
point equality comparisons are not a good way to go about things.

I believe the dyesub driver relies entirely on matching paper names
rather than dimensions, so that should be okay. But I'll have a good
look.

That has other hazards of its own.

Post by Solomon Peachy
This new stuff will surely lead to a major API/ABI bump, so IMO it would
be a good time to rethink (if not outright eliminate) the public paper
API as well. Basically, I would finish what I started with those
patches I posted a while back.

Yes, this is a major API change. I don't know that it's enough to
call it version 6, but it certainly merits 5.3 (or 5.4, if we continue
the old even scheme).
If we're going to do that, though, we might as well decide what else
needs to change. The paper API would be a good place to start, but
remind me what changes you wanted to make?

Post by Solomon Peachy
(And that said, we should probably do a 5.2.13 point release in the
near future to fix the A4 paper and other bugs in 5.2.12)

Let's make sure we have all of those fixed; it didn't sound like
Gernot was entirely convinced.

Sorry if it sounded that way. The discussion about the A4 problem
morphed into various other discussions relating to automatic media
size detection.
In short, I am perfectly happy with the A4 paper bug fix several weeks ago.

What is still unfinished is the function to pass the exact papersize
(only width so far) in 1/600 inch units to the printer (in ESC (p
command). I need to create the function and put the code there.
Furthermore, I want to change Oufuku Hagaki to be oriented the
otherway, since this is how the Canon driver sees it apparently (same
orientation as Hagaki: same height but double the width).

I've also got to look at the job level code to add support for the ESC
(u command properly (different parameter for even and odd pages).

Plenty of printers that need to be added, but that can come later.

Best regards,
Gernot Hassenpflug

[Solomon Peachy]

Post by Robert Krawitz
Anyone want me to push the branch to play with?

I'd love to see this, yes. :)

- Solomon

[Robert Krawitz]

Post by Solomon Peachy

Post by Robert Krawitz
Anyone want me to push the branch to play with?

I'd love to see this, yes. :)

OK, pushed units-branch.

[Gernot Hassenpflug]

Post by Gernot Hassenpflug

Post by Robert Krawitz

Post by Solomon Peachy

Post by Robert Krawitz
You and Gernot are going to have to be very careful how you handle
paper sizes where the printer recognizes specific sizes. Floating
point equality comparisons are not a good way to go about things.

Hello,
I understand that comparing floating point values by equality is out
of the question.
Since the final units are in 1/600 printer units, I assumed that the
way to go about it is to cast the gutenprint internal variable to an
(unsigned) integer for comparison to the exact value (also unsigned
integer) expected by the firmware. How that casting (if that is the
right word) happens, with rounding up or down, would need some more
thought.
It does not matter to me right now what gutenprint calculated, since
the value will be set unconditionally, but in the custom papersize
case the calculated value should be used after conversion to unsigned
integer in 1/600 units.

/../

Post by Gernot Hassenpflug

Post by Robert Krawitz

Post by Solomon Peachy
(And that said, we should probably do a 5.2.13 point release in the
near future to fix the A4 paper and other bugs in 5.2.12)

Let's make sure we have all of those fixed; it didn't sound like
Gernot was entirely convinced.

Sorry if it sounded that way. The discussion about the A4 problem
morphed into various other discussions relating to automatic media
size detection.
In short, I am perfectly happy with the A4 paper bug fix several weeks ago.
What is still unfinished is the function to pass the exact papersize
(only width so far) in 1/600 inch units to the printer (in ESC (p
command). I need to create the function and put the code there.
Furthermore, I want to change Oufuku Hagaki to be oriented the
otherway, since this is how the Canon driver sees it apparently (same
orientation as Hagaki: same height but double the width).

Any thoughts on how to make Oufuku Hagaki work? I suppose changing the
name in papers.xml is a bad idea, what I want is Oufuku Hagaki defined
as w420h283, since this is in line with Canon printers. Currently we
have there the landscape version.
So the definition is of the wrong orientation, width and length should
be transposed, otherwise the firmware will see the wrong dimensions.

Post by Gernot Hassenpflug
I've also got to look at the job level code to add support for the ESC
(u command properly (different parameter for even and odd pages).

Still need to look at this, been busy with the papersize fixing part still.

Regards,
Gernot Hassenpflug

[Robert Krawitz]

Post by Gernot Hassenpflug

Post by Robert Krawitz
You and Gernot are going to have to be very careful how you handle
paper sizes where the printer recognizes specific sizes. Floating
point equality comparisons are not a good way to go about things.

Hello,
I understand that comparing floating point values by equality is out
of the question.
Since the final units are in 1/600 printer units, I assumed that the
way to go about it is to cast the gutenprint internal variable to an
(unsigned) integer for comparison to the exact value (also unsigned
integer) expected by the firmware. How that casting (if that is the
right word) happens, with rounding up or down, would need some more
thought.
It does not matter to me right now what gutenprint calculated, since
the value will be set unconditionally, but in the custom papersize
case the calculated value should be used after conversion to unsigned
integer in 1/600 units.

If the printer needs 1/600" units, you need to use an internal unit
size of the LCM of 72 and 600 (the GCD of 1/72 and 1/600). That would
be 1/1800. So you'd need to multiply the points by 25, cast it to an
int, and divide by 3.