How to compile Gutenprint with DefaultPageSize A4 ?

Hello,

currently I am cleaning up our (i.e. the openSUSE/Novell) package
"gutenprint" to provide it in full compliance to upstream.

In particular I do no longer apply any patches.

But it seems there is no configure option to compile Gutenprint
with DefaultPageSize A4 in its PPDs.

Do I miss something or is DefaultPageSize Letter really hardcoded
in the sources so that I still need a patch to change it?

Kind Regards
Johannes Meixner
--

-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

Re: How to compile Gutenprint with DefaultPageSize A4 ?

   Date: Wed, 1 Sep 2010 15:12:53 +0200 (CEST)
   From: Johannes Meixner <jsmeix <at> suse.de>

   currently I am cleaning up our (i.e. the openSUSE/Novell) package
   "gutenprint" to provide it in full compliance to upstream.

   In particular I do no longer apply any patches.

   But it seems there is no configure option to compile Gutenprint
   with DefaultPageSize A4 in its PPDs.

   Do I miss something or is DefaultPageSize Letter really hardcoded
   in the sources so that I still need a patch to change it?

It's not precisely hard coded; it's simply the first matching size in
the list, which makes it the default.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

Re: How to compile Gutenprint with DefaultPageSize A4 ?

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

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

Re: Identifying color options

On Aug 30, 2010, at 3:23 AM, Kai-Uwe Behrmann wrote:
> ...
> Meta data in ICC profiles:
> + needs special tools to embedd and edit the PPD options
> + tools are particially availabel
> + scales well many other device class applications want to support

- break as soon as driver options are changed

> Installation
> Presets:
> + more secure workflow
> + works nice for canned profiles coming with the print driver
> - needs admin privileges
> - does not scale to thierd party and custom profiles
> 
> Meta data in ICC profiles:
> + more secure workflow

How?

> + works nice for canned profiles coming with the print driver
> + needs no admin privileges (other than for global installation)

- needs admin privileges

> + scales well to thierd party and custom profiles
> + no special installation program, just copy into profile path

- tied to specific driver version(s)

> Usage
> Presets:
> + pretty assignment of ICC profiles to print options
> - apps have to be updated to make use of

No, just the toolkits and/or common print dialog need to be updated.

> Meta data in ICC profiles:
> + pretty assignment of ICC profiles to print options
> - apps have to be updated to make use of

Again, this is a toolkit issue; most applications should not be doing their own print dialogs...

> 
> 
> 
> Internationalisation is possible with both systems.
> As a application and system developer the ICC meta tag convinces me much 
> more than a solution which puts all logic inside a specialised PPD + ICC 
> profiles package.
> 
> kind regards
> Kai-Uwe Behrmann
> -- 
> developing for colour management 
> www.behrmann.name + www.oyranos.org
> 
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users 
> worldwide. Take advantage of special opportunities to increase revenue and 
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Gimp-print-devel mailing list
> Gimp-print-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

Re: Identifying color options

Am 01.09.10, 08:37 -0700 schrieb Michael Sweet:
> On Aug 30, 2010, at 3:23 AM, Kai-Uwe Behrmann wrote:
>> ...
>> Meta data in ICC profiles:
>> + needs special tools to embedd and edit the PPD options
>> + tools are particially availabel
>> + scales well many other device class applications want to support
>
> - break as soon as driver options are changed

With a new driver the old ICC profile is not valid anyway. 
So thats intentional and correct. A way to display the non matching ICC 
profiles on bottom of a profile selector list would be useful.

>> Installation
>> Presets:
>> + more secure workflow
>> + works nice for canned profiles coming with the print driver
>> - needs admin privileges
>> - does not scale to thierd party and custom profiles
>>
>> Meta data in ICC profiles:
>> + more secure workflow
>
> How?

As the PPD options and a properly prepared ICC profile can be checked to 
match or not to. To remember, osX has a similiar approach since years with 
storing monitor IDs inside a special tag in display ICC profiles and check 
if the profile matches the current device. Matching ICC profiles are 
placed on top of the ICC profile selector for that device. Non matching 
can even be discarted on osX SL.
The new ICC meta tag design is just a generalisation of that approach.

>> + works nice for canned profiles coming with the print driver
>> + needs no admin privileges (other than for global installation)
>
> - needs admin privileges

Users can of course install ICC profiles into their private ICC profile 
paths. Say $HOME/.local/share/color/icc needs not admin rights.

>> + scales well to thierd party and custom profiles
>> + no special installation program, just copy into profile path
>
> - tied to specific driver version(s)

Again, thats intentional. Even canned profiles must change if the driver 
changes its colour rendering. Its like a ABI break to speak in developers 
tongue.

>> Usage
>> Presets:
>> + pretty assignment of ICC profiles to print options
>> - apps have to be updated to make use of
>
> No, just the toolkits and/or common print dialog need to be updated.
>
>> Meta data in ICC profiles:
>> + pretty assignment of ICC profiles to print options
>> - apps have to be updated to make use of
>
> Again, this is a toolkit issue; most applications should not be doing their own print dialogs...

Thats merely a detail outside of the proposal.

>> Internationalisation is possible with both systems.
>> As a application and system developer the ICC meta tag convinces me much
>> more than a solution which puts all logic inside a specialised PPD + ICC
>> profiles package.
>>
>> kind regards
>> Kai-Uwe Behrmann
>> --
>> developing for colour management
>> www.behrmann.name + www.oyranos.org
>>
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> Gimp-print-devel mailing list
>> Gimp-print-devel <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
>
>

Mit freundlichen Grüßen
Kai-Uwe Behrmann
--

-- 
Programmierung für Farbmanagement
www.behrmann.name + www.oyranos.org

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

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

Re: Identifying color options

Hi :)

On 01/09/10 16:59, Kai-Uwe Behrmann wrote:

 >> - break as soon as driver options are changed

 > With a new driver the old ICC profile is not valid anyway. So thats
 > intentional and correct. A way to display the non matching ICC
 > profiles on bottom of a profile selector list would be useful.

The breakage as soon as driver options are changed is also no problem at 
all when the metadata in the ICC profile contains sufficient data to 
inform the user *why* a particular profile is no longer valid, and how 
the situation can be resolved.  That's the biggest issue with ICC 
profiles currently - that they're relatively inscrutable and when 
something drifts it can be very hard to pin down the cause.  (Different 
batch of ink?  Paper?  Did I accidentally change a driver setting?  Or 
did I install a new version of the driver?)

> Again, thats intentional. Even canned profiles must change if the driver
> changes its colour rendering. Its like a ABI break to speak in
> developers tongue.

At the risk of going off on another tangent, what we currently lack is 
any way of signalling whether or not a new version of the driver will 
invalidate profiles.  Can we include some kind of serial number in the 
PPD that will be bumped when, and only when, some change that affects 
colour response is made?

(In PhotoPrint I use an MD5 hash of a "standard" print job to detect 
output changes, but that's not a viable solution for a higher-level 
application that never sees the raw printer data.  It's also no help 
whatsoever in pinpointing which option change has caused the discrepancy.)

All the best
--
Alastair M. Robinson

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

Re: Identifying color options

   Date: Wed, 01 Sep 2010 20:25:46 +0100
   From: "Alastair M. Robinson" <blackfive <at> fakenhamweb.co.uk>

   On 01/09/10 16:59, Kai-Uwe Behrmann wrote:

    >> - break as soon as driver options are changed

    > With a new driver the old ICC profile is not valid anyway. So thats
    > intentional and correct. A way to display the non matching ICC
    > profiles on bottom of a profile selector list would be useful.

   The breakage as soon as driver options are changed is also no
   problem at all when the metadata in the ICC profile contains
   sufficient data to inform the user *why* a particular profile is no
   longer valid, and how the situation can be resolved.  That's the
   biggest issue with ICC profiles currently - that they're relatively
   inscrutable and when something drifts it can be very hard to pin
   down the cause.  (Different batch of ink?  Paper?  Did I
   accidentally change a driver setting?  Or did I install a new
   version of the driver?)

Neither is it a problem (as far as driver options, at any rate) if the
PPD files are locked down so that any options that can affect color
can't be changed by the user.

   > Again, thats intentional. Even canned profiles must change if the driver
   > changes its colour rendering. Its like a ABI break to speak in
   > developers tongue.

   At the risk of going off on another tangent, what we currently lack
   is any way of signalling whether or not a new version of the driver
   will invalidate profiles.  Can we include some kind of serial
   number in the PPD that will be bumped when, and only when, some
   change that affects colour response is made?

Any suggestions about how to automate it, so that the coder doesn't
have to remember to change something manually?

   (In PhotoPrint I use an MD5 hash of a "standard" print job to
   detect output changes, but that's not a viable solution for a
   higher-level application that never sees the raw printer data.
   It's also no help whatsoever in pinpointing which option change has
   caused the discrepancy.)

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

Re: Identifying color options

On Monday, August 30, 2010 05:01:47 am Alastair M. Robinson wrote:
> I'm not 100% sure I understand you there - do you mean, for example, a 
> scanner's ICC profile could hypothetically contain XSane exposure, 
> gamma, contrast settings, in the same way as printer settings are 
> embedded in a printer profile?

XSane might not be a good example since it always scans in raw mode when color 
management is enabled (IE. settings like exposure, gamma are not used).  But 
another example where this would apply is to UFRAW where the profile meta data 
would have information on settings like exposure, gamma and so on.

Unlike the printer case where the logic to handle this could (should?) is 
isolated in the common print dialog input apps like RAW conversion programs 
and scanning software will need to be made aware of this meta data for this to 
work.

Hal

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

Re: Identifying color options

Am 01.09.10, 21:03 -0400 schrieb Robert Krawitz:
>   Date: Wed, 01 Sep 2010 20:25:46 +0100
>   From: "Alastair M. Robinson" <blackfive <at> fakenhamweb.co.uk>
>   At the risk of going off on another tangent, what we currently lack
>   is any way of signalling whether or not a new version of the driver
>   will invalidate profiles.  Can we include some kind of serial
>   number in the PPD that will be bumped when, and only when, some
>   change that affects colour response is made?
>
> Any suggestions about how to automate it, so that the coder doesn't
> have to remember to change something manually?

Maybe the Gutenprints unprint command of a reference version can be 
applied in a test scenario to detect any changes. E.g. 5.0 is considerd
a reference and all upcomming versions are compared to unprint-5.0 .
Once it breaks eigther bump to Gutenprint 6.0 then thats reflected in the 
PPD. Or bump a *GutenprintColorAPI variable inside PPD?

Not shure if it makes sense. Its just an idea.

>   (In PhotoPrint I use an MD5 hash of a "standard" print job to
>   detect output changes, but that's not a viable solution for a
>   higher-level application that never sees the raw printer data.
>   It's also no help whatsoever in pinpointing which option change has
>   caused the discrepancy.)

kind regards
Kai-Uwe Behrmann
--

-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

Re: How to compile Gutenprint with DefaultPageSize A4 ?

Hello,

On Sep 1 08:20 Michael Sweet wrote (shortened):
> On Sep 1, 2010, at 6:32 AM, Robert Krawitz wrote:
>> ...
>>  Do I miss something or is DefaultPageSize Letter really hardcoded
>>   in the sources so that I still need a patch to change it?
>>
>> It's not precisely hard coded; it's simply the first matching size in
>> the list, which makes it the default.
>
> Moreover, the default page size is generally replaced by cupsd
> when you add the printer.

... depending on the DefaultPaperSize setting in /etc/cups/cupsd.conf
since CUPS 1.4.

Finally for openSUSE the actual DefaultPageSize is set by YaST
depending on whether or not the user selected "A4" or "Letter"
when he added a print queue with YaST.

Conclusion:
There is no such thing as THE default for the DefaultPageSize 

By the way:

http://www.cups.org/documentation.php/doc-1.4/ref-cupsd-conf.html
reads:
"DefaultPaperSize ... The default is Auto which uses a paper size
  appropriate for the system default locale."

I wonder what exactly "the system default locale" should be?

As far as I know there is no such thing as THE system default locale.

According to how I understand the current implementation
in CUPS 1.4.4 in scheduler/conf.c the actual behaviour of cupsd
depends on whether or not libpaper is available and as fallback
the DefaultLanguage setting in /etc/cups/cupsd.conf which defaults
to "en" is used which results the DefaultPageSize "Letter".
It might be actually more complicated with cupsLangGet() effects
which seem to use the current user's environment locale setting.

For example we (i.e. openSUSE/Novell) do usually not use libpaper,
of course probably except in some of our very special products.
If libpaper is used, scheduler/conf.c calls systempapername()
which seems to read the PAPERCONF environment variable with
highest priority so that again the DefaultPageSize seems
to depend on the current user's environment setting.

I am really no expert regarding the hell of localization but
it seems the above indicates that there is really no such
thing as THE system default locale because each particular
system with its particular users may have its own kind
of "system default locale".

Please do not misunderstand me.
I do not complain at CUPS how it determines a default for the
DefaultPageSize - I do not complain at all - I just like
to point out that on each particular system a different default
for the DefaultPageSize might be the result so that two persons
who talk about the issue will probably not come to a common
understanding how this stuff works.

In the end whatever automatism to set the DefaultPageSize
cannot work in a way which is commonly understood so that
the admin who set up a queue must specify its DefaultPageSize
to make sure the queue is set up as he really wants.

Kind Regards
Johannes Meixner
--

-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd