Web Interface: page "admin/?op=set-printer-options" doesn't display names

[michaelrsweet]

Version: 1.2rc3
CUPS.org User: pipitas

Screenshot attached....

Somehow the web interface's display of the options is br0ken.

Again, used with a modified "make test" target. (I changed the port to 10631, and modified the "1 -- no load test to let it keep running after it has created the cups-str-*.html report).

Don't say that I'm using b0rken PPDs :-) Because kprinter (after adapting the IPP_PORT) as well as the lpoptions command display everything correctly:

kurt@soprano:~> IPP_PORT=10631 lpoptions -p test-1 -l
PageSize/: *Letter Legal Executive Tabloid A3 A4 A5 B5 EnvISOB5 Env10 EnvC5 EnvDL EnvMonarch
PageRegion/PageRegion: Letter Legal Executive Tabloid A3 A4 A5 B5 EnvISOB5 Env10 EnvC5 EnvDL EnvMonarch
MediaType/: *Plain Bond Special Transparency Glossy
InputSlot/: *Tray Manual Envelope
Resolution/: 75dpi *100dpi
ColorModel/: *CMYK RGB Gray

[michaelrsweet]

CUPS.org User: mike

Please attach the PPD file for the queue.

Also, what locale (command-line) and language preferences (web browser) do you have set?

FWIW, the display of the options clearly shows that the UI text is blank for those options, so I'm guessing there is, in fact, something wrong with the PPD file. We need the file to diagnose this problem...

[michaelrsweet]

CUPS.org User: pipitas

The PPD is the "testps.ppd" from the test subdirectory...

I also noticed that the "translation" part of the optionname strings was missing when I tested with the lpoption commandline. Therefore I did run cupstestppd against it, which did not complain. Looking at the PPD in an editor, I can't see anything weird (the translations are there behind the slashes).

Therefor I assumed this must be a parsing error somewhere in the *.cgi and lpoptions commandline parts (assumption was re-inforced by kprinter's ability to handle it correctly).

Language settings:
commandline: LANG=en_US.UTF-8
kprinter: same
browser: same (Konqueror)
browser: en-US (Firefox)

[michaelrsweet]

CUPS.org User: mike

OK, I just used the make test environment to test with the testps.ppd file and was unable to reproduce this problem.

What Linux distro, compiler, configure options, etc. are you using?

[michaelrsweet]

CUPS.org User: pipitas

• SUSE 10.0
• gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)
• glibc 2.3.5
• ./configure --program-suffix=12svn --with-ipp-port=20631
  --enable-ssl --enable-browse-short-names=no
  --with-domainsocket=/tmp/.CUPS.domainsock.kp

What else could be interesting?

More info: it happens with any PPD and all options.

However, I found one PPD that shows up as "Media Size" and "Media Source" in the web interface (it's the HP Mopier 320 one). A closer look shows that the *OpenUI sections for PageSize, PageRegion and InputSlot all do not have a "human readable" translation for the options.

I edited the PPD and removed the translations for some options as well as some option values (it still validates against cupstestppd). Now exactly the options without the translations show up (in their computer-readable name, of course).

Screenshot and edited PPD attached.

[michaelrsweet]

CUPS.org User: mike

OK, how about the script you are using to run cupsd and the cupsd.conf file you are using?

[michaelrsweet]

CUPS.org User: pipitas

It can't be my modifications to the scripts...

...because happens in the same way if I run an un-altered "make test", choosing the option "0 - No testing, keep the scheduler running for me (all systems)" and whatever SSL/TLS choice there is.

Next, I'll recompile everything on a different system and report again.

[michaelrsweet]

CUPS.org User: pipitas

Update: a completely fresh install of SUSE-10.0 on a different box; SVN co r5436; compiled with the same configure options named above ("--program-suffix=12svn --with-ipp-port=20631 --enable-ssl --enable-browse-short-names=no --with-domainsocket=/tmp/.CUPS.domainsock"):

• installing into the system with "make install" (with no change
  of default cupsd.conf), started cupsd as root (!); added printer
  via web interface:
  --> problem is not there.
• running "make test" with default script, as non-root user "kurt":
  --> problem is there.

Note, that the default cupsd.conf that this build gave me looks like this:
Browsing On
LogLevel info
Listen localhost:20631
Listen /tmp/.CUPS.domainsock

The "make test" script gives this:
Browsing Off
LogLevel debug
Listen 127.0.0.1:20631
User kurt

I'll have to go to bed now. The question remains, if it is somehow the combination of TCP socket with domain socket that does cause something weird, or if it is just the fact that the one is running as root, one as user....

[michaelrsweet]

CUPS.org User: mike

Is the latter example (the "make test" example) a typo? The "make test" target always uses port 8631...

I just did a fresh build on a different system, ran "make test" with option 0, and added a printer via the web interface using the testps.ppd file. I do get this problem on that system, just not on my main development system...

Looking into it some more...

[michaelrsweet]

CUPS.org User: mike

Fixed in Subversion repository.

The problem was a missing symlink for the charmaps directory. This directory provides the mapping from the PPD encoding to Unicode - when missing, it was unable to copy the UI text and left an empty string...