Changing paper type does not have any effects

I think saivann is the go-to-guy here since he packaged the drivers for Ubuntu

Of course, I get notification for all bugs for my brother packages :) .

The extra package contains /usr/Brother/inf/brMFC5440CNrc and /usr/Brother/inf/brMFC5440CNfunc files that have +w permissions and that contains configuration values for your printer. I suspect that the problem is here because these files contains "letter" as the paper type and these values does not seem to change even when the parameter is changed through cupsys. But first of all, to make sure that this problem is not specific to our packages, can you uninstall our package, install the one from Brother and test if this bug also happens with the official driver packages?

http://solutions.brother.com/linux/en_us/

I have trouble installing the original Brother drivers.
I will investigate in that and provide more information later.

But I can confirm that the switch between the letter-format and the A4-format worked just fine in Feisty and Gutsy with the drivers from the brother website.

This would be important to see if this bug happens with Brother packages in Hardy if you can install these packages. Don't forget to uninstall our packages before installing the Brother ones. You might also try

sudo chmod 777 /usr/Brother/inf/brMFC5440*

reboot your computer, and then try again to change the letter format.

Thanks for testing this.

The command

sudo chmod 777 /usr/Brother/inf/brMFC5440*

did not do anything.

Also when all ubuntu packages are removed.
The Brother mfc5440cnlpr-1.0.2-1.i386.deb -package installed just fine.

But the Brother cupswrapper-package gives this error:

micha@M2N:~$ sudo dpkg -i --force-all cupswrappermfc5440cn_1.0.0-1_i386.deb
(Reading database ... 103318 files and directories currently installed.)
Preparing to replace cupswrappermfc5440cn 1.0.2-3 (using cupswrappermfc5440cn_1.0.0-1_i386.deb) ...
lpadmin: The printer or class was not found.
 * Restarting Common Unix Printing System: cupsd [ OK ]
 * Restarting Common Unix Printing System: cupsd [ OK ]
Unpacking replacement cupswrappermfc5440cn ...
Setting up cupswrappermfc5440cn (1.0.0-1) ...
/usr/share/cups/model/brmfc5440cn_cups.ppd: No such file or directory.
dpkg: error processing cupswrappermfc5440cn (--install):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 cupswrappermfc5440cn

So I really cannot test if I may be able to change from "letter" to "A4" with the Brother packages.
Any solutions for installing the package?

The Brother package assumes the presence of a /usr/share/cups/model directory. Simply do

sudo mkdir /usr/share/cups/model

and try to install the package again.

After playing around a little bit more with the ubuntu-package and editing the file

/usr/Brother/inf/brMFC5440CNre

manually and setting PaperType=A4 instead of PaperType=Letter

it works like expected and the test page is actually printed using A4.
So that's where the Problem lies.

Will try to test the original Brother packages now after Till's advice (Thanks!).

Thank you Till.
That really did the trick and the Brother package installed fine.

And I was actually able to switch back and forth between "Letter" and "A4" with the original Brother package.

Hope this helps and you guys will be able to solve the problem within the ubuntu package.

Keep up the good work.

Thank you till.
That really did the trick and the Brother package installed fine.

And I was actually able to switch back and forth between "Letter" and "A4" with the original Brother package.

Hope this helps and you guys will be able to solve the problem within the ubuntu package.

Keep up the good work.

I've got the same problem with my DCP-120C and the Hardy Brother Drivers.
Before updating I were using the original Brother drivers without this problem and also on my laptop I didn't have this problem in an earlier state of the Hardy driver.

Editing /usr/Brother/inf/brDCP110Cr solved this problem.

Wouldn't it be nice, if the installer asked whether A4 or Letter should be used? Or is it possible for the driver to do this automatically by a locale-setting?

FriedChicken : Are you sure that you did not have this problem with my first version of these packages? I will try to work on this by the next days before Hardy final release.

Thank you guys!!!

Editing the /usr/Brother/inf/brMFC5840CNre solved this problem. Now i can print in A4 :).

Yes, I'm nearly sure.
But I've tried the first version of your packages on a new Hardy Heron Alpha. Now I had this problem on an updated System (from Gutsy to Hardy Beta) which formerly used the original drivers. Could it be that the original drivers aren't replaced correctly by the Hardy drivers?

I've opened a new bug #220328 that is at least related or even subordinate.

I'm surprised that this does not happen with actual Brother packages since when I test them, they have the same behavior and they don't update /usr/Brother/inf/br*rc and I have no printer to test this deeper.. Also, Brother website seems to say that changing printer settings needs to be done through their tools and not through cupsys : http://solutions.brother.com/linux/sol/printer/linux/printsetlpr.html

I don't assign this bug to me anymore. If anyone can take this job, please go for it. If I find a cheap Brother printer, I'll start to work on this again. Sorry if I can't fix this in a short time.

Saïvann, can you check whether your fix from bug 219509 also applies here? Probably you should apply the fix (my approved debdiff) to all your cups-wrapper packages.

Till : No it doesn't. I looked a sample of all type of PPDs (ac, bh7, extra, laser, laser1 & mfcsomething) and laser1 was the only one that had "" missing in the PPD files. Note that all PPDs files are generated from a script that contains a sample of the PPD file. The sample for ac, bh7, extra, laser, and mfcsomething were already correct, so this issue seems to be different.

As far as I could analyzed the problem not the lpr-driver but the cupswrapper has a bug.
In my case the brlpdwrapperDCP110C (or ~MFC210C) filters the cups arguments and sends them to brprintconfij2 which changes brDCP110Crc. Manually running brprintconfij2 works but only as root. So the bug is likely to be in the brlpdwrapperPRINTER-scripts or a problem of insufficient permissions.

I tried understand the script from brother (which wasn't easy for me because I know neither bash- nor csh-scripting) and then compared it to your file. The only difference I found was in line 462 (but there could be more):
   set Default=`echo "$Default" |sed s/" "//g |sed s/" "//g ` [your file]
   set Default=`echo "$Default" |sed 's/\" \"//g' |sed 's/\" \"//g' ` [Brother]
I haven't a clue what that means but it's obviously a difference. Was this intended in some way?

Well, I still don't know what's the difference in the line withe the sed-command but I activated debugging for the wrapper-script. I've attached the log.
For me it seems as if the script (which runs as "lp") needs writing access to /usr/Brother/inf.

Besides: I found "/usr/./././Brother/" several times. What does this mean? Is this a workaround?

Sorry, one supplement:
Line 462 which I mentioned above hasn't got a difference. Looking at it twice I recognized that the \ probably only masks the ".

FriedChicken : I will compare all permissions, but before all, did you test the Brother packages? In my case, the original Brother packages does not modify anything in /usr/Brother/inf when changing parameters through cupsys, so we may lose time if we try to find a difference between the Brother packages and our packages if the bug also exist in the Brother packages.

/usr/./././Brother/ = /usr/Brother/, it's a trick to avoid /usr/local/Brother even in binaries, you can ignore this.

Yes, the original Brother drivers edit files in /usr/local/Brother/inf/:
As you probably know, the postinstall-script calls a script (cupswrapperPRINTER) that generates the ppd-file and the cupswrapper-script (in my case brlpdwrapperDCP110C). Besides of the path the script is exactly the same as yours. This script calls a programm that edits brPRINTERrc.
After that cupswrapperPRINTER sets the permissions:
   chmod a+x $brotherlpdwrapper
   chmod a+w /usr/local/Brother/inf/brMFC210Crc
   chmod a+w /usr/local/Brother/inf

As I said I'm no expert in scripting but I think my interpretation of the script should be right ...

Maybe it would be better not to let everyone write into that folder but make the folder and the files owned by the user and group "lp".

FriedChicken : You can test it, what if you just change the owner and permissions of /usr/Brother/inf, does it fix the issue ?

sudo chown root:lp /usr/Brother/inf
sudo chmod 775 /usr/Brother/inf

Well, I've found a solution ...
I will upload a patch and explain the solution later on. But first I have to polish the patch a bit.

As the bug's in the cups-wrapper I set the status as "In Progress" and mark the lpr-driver as "Invalid".

It really wasn't easy to find the solution for the problem and it took me some time ...
(as I've already said I have no experience in bash-scripting)

The problem is a bit complex and consists of three parts:
1. wrong set permissions (already solved, see above)
2. incorrect generated cupswarpper-script (probably a problem with sed&awk if you used that)
3. problems that probably already exist in the original driver (I will test that later on, but I can't imagine something else)

Probably it's the best if I explain it using diff-excerpts:

Category 2:

> 513c531
> < echo $5 |tr " " n > $INPUT_TEMP_OPTIONS
> ---
> > echo $5 |tr " " '\n' > $INPUT_TEMP_OPTIONS
$5 wasn't seperated correctly (with a line feed) anymore

> 462c480
> < set Default=`echo "$Default" |sed s/" "//g |sed s/" "//g `
> ---
> > set Default=`echo "$Default" |sed s/" "//g |sed s/" "//g `
Second sed has a TAB between both " instead of a space

Category 3:

> 62a65,80
> > Resolution=Fast0 "-reso 300 -md PLAIN -doc GRAPH" \
> ...
> Resolution=Highest2 "-reso 1200x6000 -md GLOSSY -doc PHOTO" \
> ...
> > Resolution=Fine4 "-reso 1200 -md SLOWDRY" \
- Added missing functionality (copied from PPD-section)
- Corrected resolution for Highest2 (1200x600just can't be true: it would be less than some other and it wouldn't use the printers whole ability), done of course also in the PPD-section

> 75,113c93,131
> < Bi-DirPrinting=OFF "-bidir OFF" \
> ...
> < PaperThickness=Thick "-thick THICK" \
> ---
> > BiDir=OFF "-bidir OFF" \
> ...
> > PaperThick=Thick "-thick THICK" \
> 117,118c135,136
> < ColorOrMono=Mono "-corm MONO" \
> < ColorOrMono=Color "-corm COLOR" \
> ---
> > MonoColor=Mono "-corm MONO" \
> > MonoColor=Color "-corm COLOR" \
> 125,128c143,146
> < HalfTone=DIFFUSION "-ht DIFFUSION" \
> < HalfTone=DITHER "-ht DITHER" \
> < ColorEnhance=OFF "-ce OFF" \
> < ColorEnhance=ON "-ce ON" \
> ---
> > HalfTonePattern=DIFFUSION "-ht DIFFUSION" \
> > HalfTonePattern=DITHER "-ht DITHER" \
> > ColorEnhancement=OFF "-ce OFF" \
> > ColorEnhancement=ON "-ce ON" \
> 135,137c153,155
> < RedKey= "-red " \
> < GreenKey= "-green " \
> < BlueKey= "-blue " \
> ---
> > Red= "-red " \
> > Green= "-green " \
> > Blue= "-blue " \
Made script compatible with the PPD-file (PPD is Ver1.01, scrpt 0.80 as probably wasn't updated together with the PPD)

> 517c535
> < if("`grep $brcommands[$i] $INPUT_TEMP_OPTIONS`" != "") then
> ---
> > if("`grep -i $brcommands[$i] $INPUT_TEMP_OPTIONS`" != "") then
case-sensitive grep leads to errors

> 532c550
> < set option_tmp=`echo $INPUT_TEMP_LINE | sed s/"$brcommands2[$i]"/"$brcommands2[$ii]"/`
> ---
> > set option_tmp=`echo $INPUT_TEMP_LINE | sed s/"BR"...

I have also patched the PPD-file because it had an error, too:
> 206c209
> < *OrderDependency: 18 AnySetup *BRColorPaperThick
> ---
> > *OrderDependency: 18 AnySetup *BRBiDir

I've added resolution-info to the PPD-file. That's not necessary but nice to have :-)

Till : What do you think?

FriedChicken : I looked at your solution and this is strange because you said that the original Brother ones were working perfectly, but your one are really different from the original Brother ones, why? Are all these modifications genuine bug fixes?

Also I tried your one with fixed permissions and nothing changed in /usr/Brother/inf/brDCP110Crc . Unfortunately, as you know, I can't test printing.

Well, I've documented all changes I made and for me it's working ...
Yes, they are all bug fixes. Some of the problems I called "Category 3" are working with the original drivers (for example page size), some others (nearly everithing else, e.g. quality settings) not because the PPD names some options else as the script expects. And to control bi-directional printing the PPD has to be patched as I've done it.

How did you test this? I recommend to use neither use Firefox nor OpenOffice.org because they seem to make trouble: bug #222602 and bug #222686
You can activate debug mode by setting DEBUG=1 in the script, the log is saved as /tmp/br_cupsfilter_debug_log. For me this was quite usefull.

The necessity to patch the PPD files because their options do not correspond with the scripts do not show only that Brother has produced a distribution nightmare but also made buggy printer driver packages.

Saïvann, are you sure when you have replaced the equally-named scripts from all the original individual driver packages by one file in the -common package plus links in the new driver packages that all these scripts were really identical?

FriedChicken : I simply replaced my PPD and filter files by your ones, which were detected and used by cupsys and I added a printer in cupsys configured with that driver, I changed the paper type and I applied my changes, and nothing changed in /usr/Brother/inf/brDCP110Crc . I just tried again everything I just described with DEBUG set to 1 instead of 0 and I did not get any outputs in the /tmp folder. I can't know if changing paper type worked because I don't have a Brother printer.. In your case, you are able to switch between A4 and Letter using cupsys and it works perfectly? Is /usr/Brother/inf/brDCP110Crc updated with your changes? If yes, there is probably something important that you modified in your side that we don't have.

Till : DCP100C does not use shared files in -common, you can refer your the Brother packaging wiki page I made for this since it's really complicate. The only thing inside the -common package is /usr/Brother/Printer/brcupsconfpt1 needed by bh7 and extra, it's not a script but a binary which we compile from source of bh7. -extra actually contains all printer drivers that did not have any source tarballs, and a good part of these should have been included in bh7 source package by Brother because they use exactly the same files. I keep them in -extra because they are orphan and use different license. To avoid collision, I keep /usr/Brother/Printer/brcupsconfpt1 in -common.

Since I don't have any source code for the printer drivers in -extra, I have no way to really verify the differences between the upstream binaries and our compiled binaries but Brother never did two different cups wrapper with the same name. Anyway, it should not have any impact on DCP110C which does not use this shared cups wrapper.

When comparing all upstream binary brcupsconfpt1 in bh7 with diff, they are all identical.
When comparing all upstream binary brcupsconfpt1 in extra with diff, all packages that have the same version number have identical files.
When comparing all compiled upstream brcupsconfpt1 in extra with those in bh7, all packages that have the same version number have identical files.

No, I haven't edited the files anymore since I attached them.
As I found out the printig job is processed after the printer gets connected and is turned on. Maybe you can simulate this by forcing an udev-rule.

I'll attach my logfile. As you will see the paper format Executive is *not* forwarded but all the other options are. I wondered about that and found out that there's a writing mistake in the script: Executive is called "Exective". So I have to patch the script again ...

After some fighting with Virtualbox I took a closer look at the original Brother drivers. They also have the Cat. 2-Problems, except of the permissions its all Brothers fault.
The only difference why it wasn't that obvious at their driver was that they set A4 as default paper size. And because letter, A5 and so on also fit on A4 the mistake wasn't that easy to recognize.

I'm really confused if Brother hasn't got a QA?
And why didn't hey just copy the PPD and the Script instead of writing a script that generates them?
Should we write Brother a bugreport?

I've contacted Brother. I'm excited if I'll hear something from them ...

Well, their answer in short:

> We confirmed our mistakes, we appreciate for the notification.
>
> But I'm sorry since thoes are older products, we do not have plans to
> release updated drivers.

Notation:
The printer isn't that old and warranty isn't over yet so it would be nice if they didn't stop driver support.

So what will happen in future? Will there be updated packages?

I could offer to patch all affected scripts and PPDs if I knew that someone would update the packages.

I think that your patches are very interesting. However, we would need somebody else to confirm that they fix the current problem, we can't upload if it is not correctly tested as we don't want to introduce accidental bugs. Can you build properly fixed source packages so your work can be tested by someone else? In my case, your patched PPD files does not modify files in /usr/Brother/inf as it should *normally* happens but I have no Brother printer to test if it works. If your patched packages don't fix the problem, at least we will know it.

Thanks for all the work you did so far. I'm currently fixing the bad permissions problem for Intrepid.

No, till now I don't know how to build packages.

But I still will try to find some testers, it shouldn't be too complicated for them to copy the two patched files:
/usr/lib/cups/filter/brlpdwrapperDCP110C has to be overwritten by this one http://launchpadlibrarian.net/14020934/brlpdwrapperDCP110C
and /usr/share/ppd/Brother/brdcp110c_cups.ppd by this one http://launchpadlibrarian.net/13949989/brdcp110c_cups.ppd

FriedChicken : If you want to try the adventure, I can say you that it's not so complicate and that if you make some mistakes, it will be easy to fix them. You can learn about packaging here :

https://help.ubuntu.com/ubuntu/packagingguide/C/

4 indispensable commands :

Get source package :
apt-get source gnucash

Build new source package once files in debian folder were updated and once you added a new version number in debian/changelog :
dpkg-buildpackage -S -sa -rfakeroot

Create a pbuilder environment to build binary packages (needed only once) :
sudo pbuilder create --distribution hardy --othermirror "deb http://archive.ubuntu.com/ubuntu hardy universe multiverse"

Build a binary package from a source package :
sudo pbuilder --build ../<filename>.dsc

At anytime if you have questions about this, don't hesitate to email me at <email address hidden> . From now on, I think that we need your work to be properly packaged and tested before we can upload it. Thanks for your hard work!

Saïvann, Till, FriedChicken,

Thanks for all the time you put in easier accessible, working drivers for Brother printers.

As we use a Brother DCP-330c overhere, we will benefit from it as well.

If you need a hand testing, I like to help. I read most of the comments so far, but -owing to lack of time- did not have a look into the attached patches. (Because of that same lack of time, it could be a while before I get back to you guys, sorry in advance)

I do not use any Ubuntu package at the moment; three laptops with each their own set of Brother-supplied drivers. Installing them was enough of a problem, so misalignments were not my first worry.

It turned out an A4/letter problem, mostly.
I could get it right more or less:
- edited the ....rc file in the inf directory by hand
- set the options in the CUPS web-interface
- (for openoffice:) set /etc/papersize to A4 instead of letter

There is a hint about x- and y-shift on openprinting :
http://forums.linux-foundation.org/read.php?36,1224,1224,quote=1

I could not find those settings on my system.

All in all: I can not promise to test 24/24, but once a week or so I must be able to do somehing about it.

Thanks for your trouble in advance!

Hello Boudewijn,

yes, that's fine. We will need some testers in the next time.
Currently we are building some patched packages.

I will have a look at your link on openprinting an will test if this affects this printer package. But I guess this is only a problem of laser printers.

We have prepared some patched packages for testing. It would be really nice if you would install them and give your opinion.

Testing the package:
Open a colour document (picture, hoempage, graph ...) and set the option "grayscale" in the printer dialogue. If the document is printed in grayscale you're likely not affected by this bug.
If the document is printed in colours you should install the patched package. Then try to print again with the option "grayscale".

Installing the patched package:
Add the following lines to /etc/apt/sources.list:
   deb http://ppa.launchpad.net/domlyons/ubuntu hardy main
   deb-src http://ppa.launchpad.net/domlyons/ubuntu hardy main
and then make a "sudo apt-get update". After that brother-cups-wrapper should be shown as available update.

Please report your experience you make with this package! Was the problem solved? Did another problem occur?

If there were some problems you can remove the patched packages again after you reported your problem:
Remove the two lines from /etc/apt/sources.list you've added an then run the following commands:
   sudo apt-get purge brother-cups-wrapper-extra
   sudo apt-get install brother-cups-wrapper-extra
Now you've installed the "normal" hardy driver package again.

Hi FriedChicken,

I will have a go this evening or tomorrow night. I'll
keep you posted.

--- FriedChicken <email address hidden> wrote:

> We have prepared some patched packages for testing.
> It would be really
> nice if you would install them and give your
> opinion.
>
> Testing the package:
> Open a colour document (picture, hoempage, graph
> ...) and set the option "grayscale" in the printer
> dialogue. If the document is printed in grayscale
> you're likely not affected by this bug.
> If the document is printed in colours you should
> install the patched package. Then try to print again
> with the option "grayscale".
>
> Installing the patched package:
> Add the following lines to /etc/apt/sources.list:
> deb http://ppa.launchpad.net/domlyons/ubuntu
> hardy main
> deb-src http://ppa.launchpad.net/domlyons/ubuntu
> hardy main
> and then make a "sudo apt-get update". After that
> brother-cups-wrapper should be shown as available
> update.
>
> Please report your experience you make with this
> package! Was the
> problem solved? Did another problem occur?
>
> If there were some problems you can remove the
> patched packages again after you reported your
> problem:
> Remove the two lines from /etc/apt/sources.list
> you've added an then run the following commands:
> sudo apt-get purge brother-cups-wrapper-extra
> sudo apt-get install brother-cups-wrapper-extra
> Now you've installed the "normal" hardy driver
> package again.
>
> --
> Changing paper type does not have any effects
> https://bugs.launchpad.net/bugs/206365
> You received this bug notification because you are a
> direct subscriber
> of the bug.
>

Is there really no one that has got some time to test this package? It shouldn't take longer than 5-10 minutes and is not risky.

FriedChicken,

Sorry for not replying any sooner. I checked black and
white printing a colour document, with varying result.
I run Kubuntu, so often I got the KDE-printing
interface. It does not allow for setting the print to
black and white for text documents.

Firefox, OpenOffice.org and the Gimp got "other"
printing dialogs.

They all allow for setting the print to black and
white "on the fly".
- firefox prints black and white
- the gimp does not honour the colour setting
- openoffice does not honour the colour setting

Do you have a suggestion for an application to use?

I have not yet installed your package. Let me find
some time for that, and I will update the ticket for
those applications by then.

--- FriedChicken <email address hidden> wrote:

> Is there really no one that has got some time to
> test this package? It
> shouldn't take longer than 5-10 minutes and is not
> risky.
>
> --
> Changing paper type does not have any effects
> https://bugs.launchpad.net/bugs/206365
> You received this bug notification because you are a
> direct subscriber
> of the bug.
>

Thank you Boudewijn

You can use Firefox 3:
Choose a homepage with not only the background colored, for example http://www.ubuntu.com
File > Print > Advantaged > Set Color/Grayscale to "Grayscale" > Print

Of course you also can try it using KDE Applications (I've tested it using KPDF and KOffice):
Open a colored document
File > Print > Properties > Driver Settings > Set Color/Grayscale to "Grayscale" > OK > Print

Sorry, forgot to say that the dialogs can be calles slightly different as I've re-translated them from German.

OpenOffice is not good for testing this because it allows to make this settings but they are not passed to the printer driver: Bug #222602 (maybe it's a good idea if somebody could mark this bug as "Confirmed").

Sorry, forgot to say that the dialogs can be called slightly different as I've re-translated them from German.

OpenOffice is not good for testing this because it allows to make this settings but they are not passed to the printer driver: Bug #222602 (maybe it's a good idea if somebody could mark this bug as "Confirmed").

As I found out the writing permissions aren't changed on updating but are set correctly on an new installation. So please try this:
Add the PPA repository
sudo apt-get remove brother-*
sudo rm -r /usr/Brother
sudo apt-get install brother-cups-wrapper-extra

After this it should work.

Hi, I use a Brother MFC 210C and Ubuntu 8.04.
I can confirm that the patched package provided by you, FriedChicken solves the problem for me.
Though I had to install it the way you described in your last comment.
Thanks & cu

FriedChicken, your package will probably fix this bug, but it has another problem:

till@till-laptop:~/ubuntu/brother-cups-wrapper-extra$ cupstestppd /usr/share/ppd/Brother/brmfc3220c_cups.ppd
/usr/share/ppd/Brother/brmfc3220c_cups.ppd: FAIL
      **FAIL** Bad Resolution choice Normal!
                REF: Page 84, section 5.9
      **FAIL** Bad Resolution choice Fine!
                REF: Page 84, section 5.9
      **FAIL** Bad Resolution choice Photo!
                REF: Page 84, section 5.9
till@till-laptop:~/ubuntu/brother-cups-wrapper-extra$

According to the Adobe specs for PPD files an option called "Resolution" can only have choices which describe numerical resolutions, like "300dpi", "600x1200dpi", ...

Can you fix the package so that the "Resolution" option is correct?

@ Till Kamppeter:

Thank you that you had some time to look at my package.

You asked me whether i could fix the PPDs so I took a look at them again: The problem is that the cupswrapper needs this alphanumerical resolutions. Changing the PPDs would make it necessary to rewrite quiet huge parts of the cupswrapper scripts.

I can see three possible solutions:
1. Ignore the syntax errors (that's not nice but applications seem to have no problem with this)
2. The resolution-part is integrated into the media-type section (this isn't nice, too but is syntactically correct)
3. Rewrite PPDs and cupswrapper (a lot of work, rewriting could lead to new problems - is it really worth that?)

What do you mean about this?

@ drop:

Thank you for testing and your notice!

FriedChicken, I did not check whether you have introduced the choices "Normal", "Fine", and "Photo" for the "Resolution" options. If it was Brother and if CUPS accepts these PPD files when creating a print queue and printing with it, then everything is OK and I will upload the package. If you have patched the Brother software to get such choices, please revert this change (as you sound in your last posting it was Brother).

When I look at the "Resolution" option in the PPD it looks like a standard PostScript option for me. Independent which names the choices have, PostScript code for changing the rendering resolution is inserted. Usually the scripts from Brother do not need to do anything with this option. So probably renaming the Resolution choices to Adobe-compliant names (and perhaps leaving the human-readable names as they are now, for GUIs) will not break anything, but check the scripts before doing any changes.

The trick I mentioned above https://bugs.launchpad.net/ubuntu/+source/brother-lpr-drivers-extra/+bug/206365/comments/49 isn't necessary any longer. I have uploaded a new brother-lpr-drivers-common package.

@ Till:
The Brother drivers (at least them for inkjet printers) don't use the postscript code although it's included in some PPDs. They use their own bash scripts to set the printer options. These scripts need the alphanumerical resolution infos as something like a identifier. For example "Normal0" is interpreted by the script as 600dpi, plain paper and graph as document type.

In order to change the resolution section of the PPDs a great part (I guess 30%) of the script has to be rewritten, because the options the resolution sets at once need to be separated.
If you think this is needed I can try to do that, but this will need some time.
As it works I suggest to leave the PPDs as they are (at least for the moment) to get this bug fixed.

FriedChicken, so leave the PPDs as they are. They are reported to work here and so we can accept them. So can I upload yout curremt package versions into the distro?

@ Till:
As I saw now the functionality for handling resolution and paper type separately is already implemented in the script.
So the the work would mainly be to separate this option inside the PPDs (there's no paper type section till now). Probably some constraints are needed so I have to read in the specification how that works ...

Do you think it's possible to release the packages as they are now? It's working for me and "drop" also confirmed it. 2 users at the German forum ubuntuusers.de wrote that it worked, too.
If yes, I would have enough time to patch the PPDs and make sure everything works correct.

BTW: Have I to increase the version number of the PPDs (*FileVersion: "1.01") that CUPS updates the file(s) in /etc/cups/ppd?

OK, I missed your last post ...
Yes, you can upload it.

Shall I patch the PPDs anyhow sometime?

I've patched one of the PPDs and it seems to work.

Shall I try to build a package that fixes this for all PPDs or isn't it worth the trouble? Saïvann told me that my packages are not in Intrepid.

Till : My knowledge is not sufficient to comment on FriedChicken so you don't need to wait for my comments on this, FriedChicken works seems to be very good. when you have time for it, your review would be appreciated. Thanks for the time you spend on it.

FriedChicken : We still have a lot of time to consider the inclusion of your packages in Intrepid. Intrepid is not to be released tomorrow and the Intrepid alpha 1 release has been delayed because of a rush of work on Hardy so I think that we should be patient on this. Your work will for sure be reviewed for Intrepid.

I am having the same problem with a Brother MFC7420 printer.
Paper size change via Applications, Kubuntu control panel, and CUPS server are not recognized.
However, I can change the settings by changing the appropriate /usr/Brother/inf file
Changing permissions had no effect.
I added the ppa repositories, and reinstalled the Brother drivers..but this did not remedy the problem (probably because the 7420 is not in the "extras" but rather the cupswrapper-laser package.
Any suggestions would be appreciated....for now, I will just edit the rc file :-(

--Jeff

Seems to be a more general problem which doesn't only affect the extra-packages.

I would offer to fix all affected packages if I knew that they will be included in Ubuntu.

FriedChicken, tell me when you have fixed them and I will upload them for you.

@ Jeff
Please execute this command "sudo echo MFC7420 >> /usr/Brother/inf/brPrintList" and then try it again.

I've never used strace before but if I interprete the output correctly your printer has to be listed in this file.

Hi FC:
Unfortunately, the "sudo echo" command gave me a permission denied (don't know why). Sudo has always worked perfectly for me in the past, and continues to work properly for other commands.
Nonetheless, when I created a file called /usr/Brother/inf/brPrintList and listed MFC7420 on the first line, things worked perfectly!!
I did notice that the brMFC7400rc file is now empty.
--Jeff

Oh, sorry. I forgot that "echo" doesn't work with sudo (that's quite complicated). But you've done it right. So brPrintList is the problem that needs to be fixed.

Hi FC:
Note that there is another file: brPrintListij which contains a list of printers.
When I added MFC7420 to that list, it did NOT fix the problem :-(
I had to make a new file as described above
--Jeff

Yes, the problem was that brPrintList was included in laser1 but only contained the laser1-printers. I've moved brPrintList to common and added the printer models from the laser packages.

Please try the following:
- remove brPrintList
- enable my PPA again if you've deactivated it:
  deb http://ppa.launchpad.net/domlyons/ubuntu hardy main
- install the updates
Hopefully everything is working now.

HI FC:
I completely uninstalled the Brother laser CUPS and lpr drivers.
Reinstalled including the common which did, in fact, add the brPrintList.
However, with this fix, still unable to change printer settings.
Now...if I change the name of the printer in brPrintList from MFC-7420 to MFC7420 (no hyphen) it works perfectly!
So, it appears that brPrintList must contain names w/o hyphen.
Also, when installing the printer, the MFC7420 (and others from the packages) does NOT appear in the list of brother printers. I had to manually search out the ppd file (under /usr/share/ppd. While this is not a problem for me, it could be disconcerting for an inexperienced user.

--Jeff

Hi Jeff, thank you fot testing.

You're right again. I copied the printer models from the compatibility list but forgot that the driver expects them to be listed without hyphen. I've corrected that and uploaded it to PPA. The new package should be built in the next (half?) hour.
Now everything *should* work, but you never know ...

At my machine the MFC-7420 *is* listed: I've installed all Brother packages and it appears quite at the bottom of the list (the 6th last or so) as "Brother MFC7420 for CUPS (en)". The list is a bit fuzzy because some printers are listed with hyphen and some others without.
Wasn't the printer detected automatically after installing the packages and turning (off and) on the printer?

Hi FC:
The latest package works perfectly :-)
However, although the printer IS detected (it shows it connected to the USB port), when I click on the printer and advance to the "printer model selection screen" and select "Brother" none of the "for CUPS" options appears. If I click on the "Other" button and navigate to the /usr/share/ppd/Brother directory, I can select the correct .ppd file and when I do so then I am offered the MFC7420 for CUPS option.
(Interestingly, if, after installing the 7420 successfully, I go back and try to install it again (thinking that the driver would be in the list) the MFC-7420 is NOT in the list of brother printers :-(
Obviously, the list is not populating from the additional printer list.

--Jeff

> The latest package works perfectly :-)

Thank you for your help

> However, although the printer IS detected (it shows it connected to the USB port), [...]

I wondered if the System Config Printer applet doesn't detect and configure your printer. I didn't mean CUPS itself. But it's interesting nonetheless.

Was your printer listed using the unpatched package? This would be quit crazy as the laser-package hasn't changed (only laser1 and common).
Otherwise it would be the best if you started a new bug so others can find it easier.

No--it was not listed under the unpatched package either.
So...configuration was not automatic
It asks me to select a printer from the list, and when I choose the Brother printers from the list of brands, the MFC-7420 is not on the list.

--Jeff

Well, it should be the best if you opened a new bug.
I tried it on another machine, too, but is wasn't reproducible, neither with original packages nor my patched ones.

Just letting you know that it works like expected (including auto-config) under Intrepid Ibex.
This was just tested with a MFC 5440CN.
Installed the packages from the repos, plugged the printer in and it worked. I was even able to change the paper size to A4.
Thank you for the good work, Fried Chicken, Saïvann and Till. And all the other testers of course.

FriedChicken: Congratulation and many thanks, according to tester comments, your work gives relevant results! If you consider that your fix is mature and ready for intrepid, can you ask Till Kamppeter to review and upload your changes to intrepid? The Release candidate approach so we should not miss the train, not after all the work you've done ;) .

Also in your final fix, can you remove csh dependency? I attach a debdiff so you can easily apply the changes to your work.

Saïvann, debdiff is OK.

FriedChicken: Can you please post a debdiff with both your fix for this bug and the removal of the csh dependency from Saïvann? Thanks.

Hi Till and Saïvann,

yes I can do that. But please give me some time. I hope I can do that tomorrow.

Hi,

I had a look at the packages.
They seem to be working so I didn't had to change "my" packages since
some time. They can be found at my PPA:
http://ppa.launchpad.net/domlyons/ubuntu/pool/main/b/

Although I didn't touch brother-cups-wrapper-laser I applied the
debdiff. But I couldn't upload it without messing up the changelog
(signature problem), so I think it's the easiest you patch the file
yourself.

FriedChicken : Looking at your repository, I see that you worked on brother-cups-wrapper-extra packages, but I don't see brother-cups-wrapper-laser package? This bug report is currently reported for laser and extra packages, is that wrong? If yes, can you update the bug report so it shows really affected packages?

Also you don't need to apply my patch to the laser1 package, I already did it. Is there some fixes that you need to apply to the brother-cups-wrapper-laser package as you did for brother-cups-wrapper-extra package? If yes, I'd like to make one debdiff that contains both your work and my work so we just upload once.

Your PPA version of brother-lpr-drivers-laser1 and brother-lpr-drivers-common packages are about another bug, and still need works. You can work at this with me in bug 264509 that I just opened.

FriedChicken : I attach a debdiff that contains all the changes you applied to the package. I fixed your changelog description to be intrepid instead of hardy and added LP: field with correct syntax so this bug gets automatically closed when the package gets uploaded. I built this package and it looks fine. However I have no brother printer to test it.

Can you review and test the debdiff and confirm to Till if he can upload it?

Bug #264509

> Is there some fixes that you need to apply to the brother-cups-
> wrapper-laser package as you did for brother-cups-wrapper-extra package?

No.

> Can you review and test the debdiff and confirm to Till if he can
> upload it?

OK

@ Till:
Yes, you can upload it.

This bug was fixed in the package brother-cups-wrapper-extra - 1.2.1-0ubuntu3

---------------
brother-cups-wrapper-extra (1.2.1-0ubuntu3) intrepid; urgency=low

  * debian/rules: Fix PPD files and brlpdwrapper* scripts. (LP: #206365)

 -- Dominic Lyons <email address hidden> Sat, 24 May 2008 16:21:32 +0100

Till : Sorry that I made it complicate, you can also upload last debdiff for bug #251972

http://launchpadlibrarian.net/17144325/debdiff-laser

FriedChicken : Thanks again for your work! :)

Symptoms of this bug still appear on Lucid with the latest packages.

I've filed a new bug and marked it as duplicate of this bug. Can someone please verify if bug 550764 qualifies as a duplicate?

As this bug here was solved I wouldn't duplacte bug #550764 and reopen this one again.