Hi,

I tested to print color image, It seems not support color PCL output.

tools/ipptransform -d socket://127.0.0.1:9100/ -m application/vnd.hp-pcl -t srgb_8 -o media=iso_a4_210x297mm examples/testfile.jpg

I dump the print file which viewed in PCLWorkx, and found that it was gray.

PWG is OK, and is enough for me. But maybe still a problem for printer that only support PCL.

Thanks.

When a "Validate-Job" operation is sent including a "printer-resolution" attribute with the value set from "printer-resolution-default", the Printer provided by ippserver will respond with status-code = client-error-attributes-or-values-not-supported (Unsupported printer-resolution resolution value.)

Attached is a test file that illustrates this. You can demonstrate the problem like so:

./ippfind -n foo -x ./ipptool -vt 'ipp://Serenity.local:8503/ipp/print/foo' ipp-test-I11.test ;

ipp-test-I11.test.txt

Does ippserver server currently support TLS encryption? Specifically thinking of LetsEncrypt chained certificates. Thanks for any information.

Daryl

We encountered an error when trying to create an ipptool .test file that contained the following directive for the request:

ATTR no-value finishings-col fakeval
# or
ATTR no-value finishings-col

The ipptool tool currently doesn't support this, but it should, so that these out-of-band values that are legitimate can be sent in requests for testing purposes.

If you checkout and build the project using "./configure && make", you can then test ippserver using "./server/ippserver -C ./test". Unfortunately, even this will fail to execute. The problem seems to be the current main.c, which starts out like so:

int                 /* O - Exit status */
main(int  argc,             /* I - Number of command-line args */
     char *argv[])          /* I - Command-line arguments */
{
  int       i;          /* Looping var */
  char      *opt,           /* Current option character */
        *authtype = NULL,   /* Type of authentication */
        *confdir = NULL,    /* Configuration directory */
                *command = NULL,    /* Command to run with job files */
        *device_uri = NULL, /* Device URI */
        *name = NULL,       /* Printer name */
        *location = (char *)"", /* Location of printer */
        *make = (char *)"Test", /* Manufacturer */
        *model = (char *)"Printer",
                    /* Model */
        *icon = NULL,       /* Icon file */
        *formats = (char *)"application/pdf,image/jpeg,image/pwg-raster";
                        /* Supported formats */

Unfortunately, the initialization of "location", "make", "model" and formats" at declaration time means that this line down below following the processing of command line arguments will always evaluate to true, preventing it from executing:

  if (confdir && (name || make || model || location || attrs || command || icon || formats || duplex || pin || ppm || ppm_color))
  {
    fputs("ippserver: Cannot specify configuration directory with printer options (-2, -M, -P, -a, -c, -f, -i, -l, -m, -s)\n", stderr);
    usage(1);
  }

If the variables are declared an initialized to NULL, like so:

  char      *opt,                   /* Current option character */
            *authtype = NULL,       /* Type of authentication */
            *confdir = NULL,        /* Configuration directory */
            *command = NULL,        /* Command to run with job files */
            *device_uri = NULL,     /* Device URI */
            *name = NULL,           /* Printer name */
            *location = NULL,       /* Location of printer */
            *make = NULL,           /* Manufacturer */
            *model = NULL,          /* Model */
            *icon = NULL,           /* Icon file */
            *formats = NULL;        /* Supported formats */

and then initialized after this check, like so:

  if (confdir && (name || make || model || location || attrs || command || icon || formats || duplex || pin || ppm || ppm_color))
  {
    fputs("ippserver: Cannot specify configuration directory with printer options (-2, -M, -P, -a, -c, -f, -i, -l, -m, -s)\n", stderr);
    usage(1);
  }
  else
  {
      // specify the defaults now that we are past testing incorrect arguments
      make = (char *) "Test";
      model = (char *) "Printer";
      formats = (char *) "application/pdf,image/jpeg,image/pwg-raster";
      location = (char *) "";
  }

then specifying a "-C" and a valid directory (like "./server/ippserver -C ./test") will run ippserver successfully.

I try to transform JPEG to IPP printer, but it can't work.
Abort with message pointer being freed was not allocated.
By the way, PDF works fine.

My OS is Mac OS X 10.11.6

➜  ippsample git:(master) ✗  tools/ipptransform -d ipp://192.168.31.168:631/ipp/print -m image/pwg-raster examples/testfile.jpg -o media=iso_a4_210x297mm 
ATTR: printer-alert=unsupported
ATTR: printer-supply=unsupported
ATTR: printer-supply-description=unsupported
STATE: media-empty-error,media-needed-error,media-empty-error,media-needed-error
ATTR: marker-colors=#000000
ATTR: marker-names=Black
ATTR: marker-types=toner
ATTR: marker-low-levels=10
ATTR: marker-high-levels=100
ATTR: marker-levels=59
STATE: none
ATTR: job-impressions-completed=1
ATTR: job-media-sheets-completed=1
ipptransform(19720,0x7fff7b8a1000) malloc: *** error for object 0x7fd1d380ce00: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
[1]    19720 abort      tools/ipptransform -d ipp://192.168.31.168:631/ipp/print -m image/pwg-raster

in-group.test.txt

As part of an EXPECT directive, ipptool cannot locate collection members when using the IN-GROUP predicate.
To EXPECT a collection member, the collection/member syntax is used. This works fine unless you also specify IN-GROUP.
Even though a WireShark capture shows the desired member is in the proper group, when using the collection/member syntax with IN-GROUP the EXPECT fails with error "got zero."

See in-group.test.txt for an example ipptoolfile that illustrates this behavior.

As far as I can tell, I followed all instructions to set up the prerequisites correctly, including the one that tells to install MuPDF v1.11.

The subsequent build process fails with a MuPDF-related error message:

[....]
Linking ippserver...
Making all in tools...
Compiling ippfind.c...
Linking ippfind...
Compiling ipptool.c...
Linking ipptool...
Compiling ipptransform.c...
ipptransform.c: In function ‘xform_document’:
ipptransform.c:2080:12: error: too few arguments to function ‘fz_new_pixmap’
   pixmap = fz_new_pixmap(context, cs, (int)ras.header.cupsWidth, (int)ras.band_height);
            ^
In file included from /usr/local/include/mupdf/fitz.h:34:0,
                 from ipptransform.c:26:
/usr/local/include/mupdf/fitz/pixmap.h:58:12: note: declared here
 fz_pixmap *fz_new_pixmap(fz_context *ctx, fz_colorspace *cs, int w, int h, int alpha);
            ^
ipptransform.c:2085:40: error: passing argument 2 of ‘fz_new_draw_device’ from incompatible pointer type [-Werror]
   device = fz_new_draw_device(context, pixmap);
                                        ^
In file included from /usr/local/include/mupdf/fitz.h:44:0,
                 from ipptransform.c:26:
/usr/local/include/mupdf/fitz/device.h:317:12: note: expected ‘const struct fz_matrix *’ but argument is of type ‘struct fz_pixmap *’
 fz_device *fz_new_draw_device(fz_context *ctx, const fz_matrix *transform, fz_pixmap *dest);
            ^
ipptransform.c:2085:12: error: too few arguments to function ‘fz_new_draw_device’
   device = fz_new_draw_device(context, pixmap);
            ^
In file included from /usr/local/include/mupdf/fitz.h:44:0,
                 from ipptransform.c:26:
/usr/local/include/mupdf/fitz/device.h:317:12: note: declared here
 fz_device *fz_new_draw_device(fz_context *ctx, const fz_matrix *transform, fz_pixmap *dest);
            ^
ipptransform.c: At top level:
cc1: error: unrecognized command line option "-Wno-tautological-compare" [-Werror]
cc1: all warnings being treated as errors
../Makedefs:141: recipe for target 'ipptransform.o' failed
make[1]: *** [ipptransform.o] Error 1
Makefile:29: recipe for target 'all' failed
make: *** [all] Error 1

I tried to build ippsample on a Raspberry Pi 3 with current Raspbian installed, following the PI.md instructions.

The make stage fails with this output:

[....]
Making all in cups...
Compiling tls.c...
In file included from tls.c:44:0:
tls-gnutls.c: In function ‘httpLoadCredentials’:
tls-gnutls.c:705:17: error: conversion to ‘int’ from ‘size_t’ may change the sign of the result [-Werror=sign-conversion]
       decoded = alloc_data - num_data;
                 ^
tls-gnutls.c: In function ‘http_gnutls_load_crl’:
tls-gnutls.c:948:14: error: conversion to ‘int’ from ‘size_t’ may change the sign of the result [-Werror=sign-conversion]
    decoded = alloc_data - num_data;
              ^
tls.c: At top level:
cc1: error: unrecognized command line option "-Wno-tautological-compare" [-Werror]
cc1: all warnings being treated as errors
../Makedefs:138: recipe for target 'tls.o' failed
make[1]: *** [tls.o] Error 1
Makefile:30: recipe for target 'all' failed
make: *** [all] Error 1

I have the required packages installed with these versions:

$ dpkg -l  libnss-mdns avahi-daemon avahi-utils  libavahi-client-dev libgnutls28-dev zlib1g-dev
    [....]
    ||/ Name                   Version         Architektur  Beschreibung
    +++-======================-===============-============-===================================================
    ii  avahi-daemon           0.6.31-5        armhf        Avahi mDNS/DNS-SD daemon
    ii  avahi-utils            0.6.31-5        armhf        Avahi browsing, publishing and discovery utilities
    ii  libavahi-client-dev    0.6.31-5        armhf        Development files for the Avahi client library
    ii  libgnutls28-dev:armhf  3.3.8-6+deb8u3  armhf        GNU TLS library - development files
    ii  libnss-mdns:armhf      0.10-6          armhf        NSS module for Multicast DNS name resolution
    ii  zlib1g-dev:armhf       1:1.2.8.dfsg-2  armhf        compression library - development

Some printers support different attributes depending on the document format being used. The Printer may limit the set of attributes reported by Get-Printer-Attributes when the operation request includes a "document-format" operation attribute , and a Client can use that to present the filtered set of choices once it has selected a document format. Similarly, the Printer may accept or reject a job creation operation request depending on whether a particular attribute is legitimate for a particular document format.

Currently there is no way to express such variances within a single Printer provided by ippserver. Separate Printers can be configured but those don't properly demonstrate this aspect of IPP.

Such an addition would require an extension to the ippserver's Print Service Configuration File format. One notion might be to adopt a convention from the venerable CUPS "ppdc" / "ppdcfile" system, which supported model variants that were delimited based on "curly bracket encapsulation" to indicate their scope.

Based on a packet trace, it seems like some printers do not include a "Content-Type: application/ipp" HTTP header in their responses, which is technically non-conformant.

ipptool should check for this and (at least) warn the user when in "test" mode.

The man- and html-help docu for ippproxy refer to the ippinfra utility in the "Description" section.

However, this repository does not contain an ippinfra tool...

If a Cancel-My-Jobs operation is performed and the "job-ids" attribute is provided, with a value containing more than one legitimate Job ID, ipptool will not put the first Job ID, but will rather send a zero (0). This will cause the operation to fail at best, and at worst, will prevent the jobs from being cancelled.

In the attached "cancel-my-jobs.test.txt" test file, a Cancel-My-Jobs operation is performed. The "job-ids" optional operation attribute is provided, whose value lists the 3 Job IDs of the jobs that are created earlier in the test.

cancel-my-jobs.test.txt

ippserver should implement the IPP System Service v1.0 specification now that it has reached prototype status.

If I run ippserver like so:

./ippserver -vv -2 "foo"

the output will show this, among other things:

[Printer foo] sides-default (keyword) one-sided
[Printer foo] sides-supported (1setOf keyword) one-sided,two-sided-long-edge,two-sided-short-edge

But if I have it load a set of configuration files (system.conf, print/foo.conf) from the local directory, and run ippserver like so:

./ippserver -vv -2 -C .

the output will show this:

[Printer foo] sides-default (keyword) one-sided
[Printer foo] sides-supported (keyword) one-sided

I can override this by specifying "side-default" and "sides-supported" in print/foo.conf but I don't think I should have to if I have provided the "-2" option.

(Similarly, I might have expected the "-2" option to make "two-sided-long-edge" the value for "sides-default"...)

If you have an ipptool test file like so:

{
DELAY 2

NAME "Get printer-uuid using an IPP Get-Printer-Attributes operation"

OPERATION Get-Printer-Attributes
Version 2.0

GROUP operation
ATTR charset attributes-charset utf-8
ATTR language attributes-natural-language en
ATTR uri printer-uri $uri
ATTR keyword requested-attributes printer-uuid

STATUS successful-ok

EXPECT printer-fake-attribute REPEAT-NO-MATCH REPEAT-LIMIT 10

}

I am seeing a 10 repeat limit and a DELAY of 2 seconds. So would that mean it would take:

1. 2 seconds for delay + 11 tries as fast as it could go (first try + 10 retries)
2. 11 tries, each with a 2 second delay
3. 10 tries, each with a 2 second delay
4. Something else?

It is my belief that it should be #2.

I see a few small issues in man pages:

man ippserver:

• command line parameter -c command should start on a line of its own.
• command line parameter `−f type/subtype,[...] should start on a line of its own.

man ippproxy:

• The Conforming to section, still says "The ippproxy program is unique to CUPS".

man ipptransform:

• The initial Name section contains a typo: "ipptran**_a**_form".
• In the Options section the following options should be starting as a new item each:
  1. −o "name=value[...name=value]"
  2. −r resolution[,...,resolution]
  3. −s {flipped|manual-tumble|normal|rotated}
  4. −t type[,...,type]
  5. −v

From May 2017 F2F discussions during CUPS plenary, we should investigate ways to use ippserver to test/certify client implementations based on the current implementor's guide - basically provide a score and/or testing summary for client developers.

• log analysis and/or "ipptool" testing tools?
• Need to define requirements to determine what we need...

Hi Michael, this is a question and wish you can give me some advice:
when I used ippserver to print a file, this will lead to a .prn file, not a pdf file
how to print to a pdf file?
thank you.

The man page and webpage for the ippproxy tool does not specify the command line switches that are actually used by the program.

It would be beneficial if ippserver could support accepting multiple "-r" options so that it could advertise more than one DNS-SD service subtype at a time.

It would be good to have a way to allow the Printer to specify a legitimate value for the "printer-strings-uri" attribute, so that strings files could be used by the Client.

The ippfind tool has the "-n" and "--name" options to specify the name. But these are regular expressions. It would be very useful for some users and some uses of ippfind (such as the IPP Everywhere Self Certification tool suite) if there was a different argument that would specify the exact name string, that didn't require all the escaping, etc. that a regular expression would require. The new argument could perhaps use the "-e" / "--exact-name" label.

Hi. I'm not sure if this is the appropriate place to ask for help, but I haven't found any place else. Hope you will be patient. I am trying to build your software on a CentOS 7.2 host and getting the following error (among other warnings):

cc1: error: unrecognized command line option "-Wno-tautological-compare" [-Werror]
cc1: all warnings being treated as errors
make[1]: *** [printer.o] Error 1

I am wondering if there are any instructions or any other kind of help to get this built?

Thanks for your time.

Regards,

Daryl

Some clients encode the value of the IPP "printer-uuid" value / DNS-SD TXT record "UUID" key value into the URI. Unfortunately, "ippserver" changes the printer's UUID after every run, which means the queue becomes invalid on some client systems (tested with OS X 10.11.6).

Moreover, if I have specified a UUID in a Printer configuration file, I see the value set early in the stream of output, but then it is overwritten later in the logging reported by ippserver. Early in the logging, where attribute definitions are read from the config file, I will see this:

[Printer foo] printer-uuid (uri) urn:uuid:0d3d8dbd-bcd1-dead-beef-76c7e04caf42
....
[Printer foo] printer-uuid (uri) urn:uuid:5accac29-2942-3a10-5367-7a4d46ec0701

and it is this second one that will be used by ippserver. That prevents me from specifying a durable UUID for the Printer.

foo.conf.txt

Reported by Smith via email - when ippserver isn't configured with a default document-format value, the Validate-Job request sent by a CUPS client is rejected based on the lack of a document-format value, which is a bug.

If an ipptool file has an expect directive in it looking at URIs, and the hostname of the Printer from its SRV record (discovered via ippfind) is using different capitalization than in the URIs reported by the Printer, ipptool will fail the expectations, even though DNS hostnames are supposed to be case-insensitive.

Example ipptool output:

I-9. Get-Printer-Attributes Operation (default)                      [FAIL]
    RECEIVED: 15678 bytes in response
    status-code = successful-ok (successful-ok)
    EXPECTED: printer-icons WITH-ALL-VALUES "HP40B034762169.local"
    GOT: printer-icons="http://hp40b034762169.local/images/printer-small.png"
    GOT: printer-icons="http://hp40b034762169.local/images/printer.png"
    GOT: printer-icons="http://hp40b034762169.local/images/printer-large.png"
    EXPECTED: printer-supply-info-uri WITH-VALUE "HP40B034762169.local"
    GOT: printer-supply-info-uri="http://hp40b034762169.local/#hId-pgInkConsumables"

Regardless of the distastefulness of the hostname or the oddness that the Printer is reporting its hostname with one capitalization in one context and another capitalization in another context, this should not be failing because ipptool should be comparing the hostname portion of a URI in a case-insensitive manner.

ippserver should publish LOC records when the printer-geo-location attribute is set.

The definition of "job-password-encryption-supported" in PWG 5100.11 section 10.4 says this:

'If the operation attribute "job-password" is supported, then this attribute MUST be supported.'

Yet if ippserver is provided with the "-P" option, it will implement "job-password-supported" but not "job-password-encryption-supported".

This can be remedied by defining "job-password-encryption-supported" and redefining "job-password-supported" in a config file or via the command line. But it really ought to do it properly and list "job-password-encryption-supported" with value "none" if no encryption is supported by ippserver.

Reference: https://snapcraft.io/docs/

We should add support for an ippsample (or maybe just "ipp") snap that provides a "universal" Linux binary that can be built automagically via build.snapcraft.io and github.

In addition to the usual snap/snapcraft.yaml stuff, we'll want a configure option and stuff in the makefiles to have a configurable prefix so that the snap commands can be "ipp.server", "ipp.tool", etc. rather than "ipp.ippserver", etc.

I'm testing ippserver functionality on a Raspberry Pi 3 running openSUSE vLeap 42.3. Compiled the current sources (latest commit was Oct 12, cc48390) on the Raspbi.

While the Raspbi on other occasions responds in a quite "snappy" way (I only log in via SSH and don't run any GUI stuff on it, though there's some installed), I find ippserver to be very hesitant in starting up.

I did first run it like this:

kp@raspi3:~/svn-stuff/git.ippsample>  server/ippserver -vvvv "Test Test"

 Using default configuration with a single printer.
 Using default data directory "/tmp/ippserver.5030".
 Using default spool directory "/tmp/ippserver.5030".
 Ignore Avahi state 2.
 Using default listeners for raspi3.local.:8000.
 serverCreatePrinter(resource="/ipp/print", name="Test Test", location="", make="Test", \
   model="Printer", icon="(null)", docformats="application/pdf,image/jpeg,image/pwg-raster", \
   ppm=0, ppm_color=0, duplex=0, pin=0, attrs=(nil), command="(null)", device_uri="(null)", \
   proxy_user="(null)", strings=(nil))
 Using ppm=0
 Using ppm_color=0
 [Printer Test Test] printer-more-info="http://raspi3.fritz.box:8000/ipp/print"
 [Printer Test Test] printer-supply-info-uri="http://raspi.local.:8000/ipp/print/supplies"
 [Printer Test Test] printer-uri="ipp://raspi3.local.:8000/ipp/print"

At this point the output pauses for quite a while. The mentioned URIs from the last three lines were not accessible, and after a timeout the browser displayed an error message.

Initially I thought it is all that is expected to happen. Then, while googling, I found other example outputs being quoted, which didn't look as disappointing as the above one.... :-)

I tried again. However, after the same output as above (which displays on the spot), I was called for dinner and left the terminal sitting there.

So I was surprised to find the screen propulated by all kinds of IPP messages returned from ippserver.

So I used the following modified command to measure the time for the process to complete its upstart, and repeated it five times:

kp@raspi3:~/svn-stuff/git.ippsample> server/ippserver -vvvv "Test Test" 2>&1 \
                                                     | tee ippserver-$(date +%H-%M-%S).log

Here are the resulting infos:

kp@raspi3:~/svn-stuff/git.ippsample> ls --full-time -gG ippserver-*.log | cut -c 19-

 2017-10-25 15:44:05.460235590 +0200 ippserver-15:42:59.log
 2017-10-25 15:49:31.887417751 +0200 ippserver-15:44:54.log
 2017-10-25 16:01:32.551159324 +0200 ippserver-15:57:34.log
 2017-10-25 16:12:28.565455783 +0200 ippserver-16:07:12.log
 2017-10-25 16:20:12.061432491 +0200 ippserver-16:17:19.log

As you can see, it took at least 66 seconds (file *-15:42:59.log) and up to 316 seconds (file ˜*16:07:12.log) for ippserver to end its "pausing" after printing the first three [Printer Test Test]-lines on screen.

What is it doing in this time?? The following screenshot shows how htop reports 100% CPU usage during that time (several minutes, as shown above):

After the startup time is over, and after the terminal has displayed all the ippserver's output, the CPU load reported by htop is back to normal:

If you watch the terminal "life" while running the commands and try to access one of the HTTP resources with a browser at the same time, you'll notice that the resource becomes available only after the terminal output has overcome the initial lag.

It isn't very obvious how one would encode, for instance, "media-col-ready" in an ATTR declaration, because of the nested collections, and the need for commas. Guessing this might be correct:

ATTR collection media-col-ready { MEMBER collection media-size { MEMBER integer x-dimension 21590, MEMBER integer y-dimension 27940 }, MEMBER integer media-top-margin 423, MEMBER integer media-bottom-margin 423, MEMBER integer media-left-margin 423, MEMBER integer media-right-margin 423, MEMBER keyword media-source "main", MEMBER keyword media-type "stationery" }

(Is it possible for parsing errors to be written out to the ippserver log? That would help too...)

I'm trying to compile on a Raspberry Pi 3 with Raspbian (with all updates as of today).

In place of MuPDF I used the checked out Git sources (from git://git.ghostscript.com/mupdf.git) as of today.

Not sure if I SHOULD use an officially released source tarball?

Anyway, I'm now seeing this error:

Making all in cups...
Making all in proxy...
Making all in server...
Making all in tools...
Compiling ipptransform.c...
ipptransform.c: In function ‘xform_document’:
ipptransform.c:2081:12: error: too few arguments to function ‘fz_new_pixmap’
   pixmap = fz_new_pixmap(context, cs, (int)ras.header.cupsWidth, (int)ras.band_height);
            ^
In file included from /usr/local/include/mupdf/fitz.h:35:0,
                 from ipptransform.c:26:
/usr/local/include/mupdf/fitz/pixmap.h:51:12: note: declared here
 fz_pixmap *fz_new_pixmap(fz_context *ctx, fz_colorspace *cs, int w, int h, int alpha);
            ^
ipptransform.c:2086:40: error: passing argument 2 of ‘fz_new_draw_device’ from incompatible pointer type [-Werror]
   device = fz_new_draw_device(context, pixmap);
                                        ^
In file included from /usr/local/include/mupdf/fitz.h:46:0,
                 from ipptransform.c:26:
/usr/local/include/mupdf/fitz/device.h:344:12: note: expected ‘const struct fz_matrix *’ but argument is of type ‘struct fz_pixmap *’
 fz_device *fz_new_draw_device(fz_context *ctx, const fz_matrix *transform, fz_pixmap *dest);
            ^
ipptransform.c:2086:12: error: too few arguments to function ‘fz_new_draw_device’
   device = fz_new_draw_device(context, pixmap);
            ^
In file included from /usr/local/include/mupdf/fitz.h:46:0,
                 from ipptransform.c:26:
/usr/local/include/mupdf/fitz/device.h:344:12: note: declared here
 fz_device *fz_new_draw_device(fz_context *ctx, const fz_matrix *transform, fz_pixmap *dest);
            ^
ipptransform.c: At top level:
cc1: error: unrecognized command line option "-Wno-tautological-compare" [-Werror]
cc1: all warnings being treated as errors
../Makedefs:138: recipe for target 'ipptransform.o' failed
make[1]: *** [ipptransform.o] Error 1
Makefile:30: recipe for target 'all' failed
make: *** [all] Error 1

README.md states about the licensing of this software:

"The tools are provided under the terms of version 2 of the GNU General Public License and GNU Library General Public License."

I read this short as "LGPL-2.0 and GPL-2.0".

LICENSE.md lists the following:

"original CUPS source code [....] provided under the terms of the GNU Library General Public License ("LGPL"), Version 2. [....] new IPP Sample source code [....] provided under the terms of the New BSD License."

I read this short as "LGPL-2.0 and New BSD".

It may be needed to put these to statements in sync in order to avoid confusion.

The current Raspberry Pi documentation needs updates:

• Build instructions
• Configuration when connected to Ultimaker or similar 3D printer

Also investigate how to provide a feed of the Pi Camera board video/snapshots.

If ipptool is called with the "-P" argument (to generate a test results .plist file) in addition to the "-t" argument (to have CUPS test report output used), there will be extraneous information written to stdout so that the test report output becomes polluted and difficult to read.

Example without the "-P" argument:

Serenity: ippsample [714]$ ./tools/ipptool -vt 'ipp://Serenity.local:8991/ipp/print/_IPP-Everywhere-Basic_' test-i9-trimmed-2.test
"test-i9-trimmed-2.test":
	Get-Printer-Attributes:
		attributes-charset (charset) = utf-8
		attributes-natural-language (naturalLanguage) = en
		printer-uri (uri) = ipp://Serenity.local:8991/ipp/print/_IPP-Everywhere-Basic_
		requesting-user-name (nameWithoutLanguage) = smitty
		requested-attributes (keyword) = printer-icons
	I-9. Get-Printer-Attributes Operation to Serenity.local              [FAIL]
		RECEIVED: 161 bytes in response
		status-code = successful-ok (successful-ok)
		attributes-charset (charset) = utf-8
		attributes-natural-language (naturalLanguage) = en
		printer-icons (uri) = https://serenity.local.:8991/ipp/print/_IPP-Everywhere-Basic_/icon.png
		EXPECTED: printer-icons WITH-ALL-VALUES "Serenity.local"
		GOT: printer-icons="https://serenity.local.:8991/ipp/print/_IPP-Everywhere-Basic_/icon.png"

Example with "-P" added:

Serenity: ippsample [715]$ ./tools/ipptool -vt 'ipp://Serenity.local:8991/ipp/print/_IPP-Everywhere-Basic_' -P '_IPP-Everywhere-Basic_.plist' test-i9-trimmed-2.test
"test-i9-trimmed-2.test":
I-9. Get-Printer-Attributes Operation to Serenity.localGet-Printer-Attributesattributes-charsetutf-8attributes-natural-languageenprinter-uriipp://Serenity.local:8991/ipp/print/_IPP-Everywhere-Basic_requesting-user-namesmittyrequested-attributesprinter-icons    Get-Printer-Attributes:
		attributes-charset (charset) = utf-8
		attributes-natural-language (naturalLanguage) = en
		printer-uri (uri) = ipp://Serenity.local:8991/ipp/print/_IPP-Everywhere-Basic_
		requesting-user-name (nameWithoutLanguage) = smitty
		requested-attributes (keyword) = printer-icons
	I-9. Get-Printer-Attributes Operation to Serenity.local              [successful-okattributes-charsetutf-8attributes-natural-languageenprinter-iconshttps://serenity.local.:8991/ipp/print/_IPP-Everywhere-Basic_/icon.pngFAIL]
		RECEIVED: 161 bytes in response
		status-code = successful-ok (successful-ok)
		attributes-charset (charset) = utf-8
		attributes-natural-language (naturalLanguage) = en
		printer-icons (uri) = https://serenity.local.:8991/ipp/print/_IPP-Everywhere-Basic_/icon.png
EXPECTED: printer-icons WITH-ALL-VALUES "Serenity.local"GOT: printer-icons="https://serenity.local.:8991/ipp/print/_IPP-Everywhere-Basic_/icon.png"        EXPECTED: printer-icons WITH-ALL-VALUES "Serenity.local"
		GOT: printer-icons="https://serenity.local.:8991/ipp/print/_IPP-Everywhere-Basic_/icon.png"

Similar misbehavior is observed when no formatting arguments are provided and the "-P' argument is either provided or not. First observed with recent debug builds of the IPP Everywhere Self Certification test suite, where the output was corrupted and difficult to read.

When there is an error in an ippserver configuration file, ippserver in some cases reports the wrong line number, which makes it difficult to fix the issue.

Attached is a ".conf" file that declares a number of "vendor-specific" attributes to exercise the attribute definition parsing, and if you selectively comment out portions of that, you observe the number reporting starts to go off in the weeds where a collection is defined. (I had to give it a .txt file extension to make attaching to Github happy...)

ippserver-data-type-test.conf.txt

Steps to reproduce:

1. Run docker file to setup, build, and run latest ippsample code
2. Run ippserver
   
3. Run ipptool from client
   

Expected output:
All tests complete successfully (or are skipped)

Actual output snippet from client below:

Comment from Mike:

• printer-config-change-{date-time,time} are explicitly supported and should be returned, and printer-icons is normally populated with a default value. The printer-supply* attributes are currently commented out since I haven't had a chance to update that code from the original CUPS sources which only supported a single printer and canned supplies. We do want ippserver to pass the self-cert tests so it can serve as an example of a conforming implementation... :)

When build in Ubuntu 16.04, it ends up with errors:

Making all in cups...
Making all in server...
Compiling client.c...
client.c: In function ‘show_media’:
client.c:1675:36: error: conversion to ‘size_t {aka long unsigned int}’ from ‘int’ may change the sign of the result [-Werror=sign-conversion]
       memcpy(tray_str, readysystem_tray, tray_len);
                                    ^
client.c: In function ‘show_supplies’:
client.c:1951:39: error: convsystemersion to ‘size_t {aka long unsigned int}’ from ‘int’ may change the sign of the result [-Werror=sign-conversion]
     memcpy(supply_text, supply_value, supply_len);
                                       ^
client.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-tautological-compare’ [-Werror]
cc1: all warnings being treated as errors
../Makedefs:141: recipe for target 'client.o' failed
make[1]: *** [client.o] Error 1
Makefile:29: recipe for target 'all' failed
make: *** [all] Error 1

It would be useful to add support for querying for the presence of published LOC records and filtering results based on proximity based on data from LOC records.

IPP Everywhere (5100.14) requires Printers to publish LOC records, but we are currently lacking a tool that would allow the PWG IPP Everywhere Self Certification test suite to validate whether the device has published a LOC record for its IPP services.

A strange and intermittent issue has come up running ipptool under windows. It only came to bite me after numerous successful runs.

It seems that ftell gets confused when various getc / ungetc operations are performed on a file that is opened in mode "r" (ascii). It is necessary to open the file in mode "rb" (binary). My file on windows had simple unix style line endings which is perhaps where the inaccuracy comes about - I'm not sure. I have confirmed the fix works.

Rather than submitting a patch I'd like to offer the code location for the change as its very simple to find. I do not feel other fopen and similar calls need to be changed from "r" to "rb" at this time but I'll be on look out now!

ipptool.c

~ line 829:	if ((fp = fopen(testfile, "rb")) == NULL)

The symptoms of the problem were weird parse errors showing "incorrect tokens" from earlier in the file. And in particular due to a collection attribute. Maybe the pattern of getc / ungetc did the trick in this. Attached is a zipped file that should hopefully not work for you and then will work after the patch.

J
testfile.zip

Hi, I have successfully been able to print using ippserver but when I use the -C /some/config/dir flag to point ippserver to a config directory it does not configure any printers. I am using a standard cups config directory with two printers defined in printers.conf. The ippserver appears to start just fine and with the verbose flag on it prints:

$ ./start-ippserver.sh
Using default spool directory "/home/daryl/ippserver".
Ignore Avahi state 2.
Using default listeners for demo.cirrusprint.com:631.
serverRun: 0 printers configured.
serverRun: 1 listeners configured.

I start the ippserver with the following command line:

/usr/bin/sudo /usr/local/sbin/ippserver -d /home/daryl/ippserver -k -p 631 -vv -C /tmp/cups.d

An interesting aside, using the -vv flag the verbosity level is much less than without the -C flag.
Any help would be appreciated, or if there are any docs I could read up on that would be great as well.

Regards,

Daryl Williams

We ought to have a tool that can take an input PWG Raster document file and check its structure and report any errors / warnings / issues with the document's structure or content.

This could be used by an "ippserver" tool as a "command" to process the input files, which could then report on structural problems with the document content submitted with a Job, and report its status accordingly.

In both, the HTML and the man page for ipptransform, the name is defined as ipptran_a_form.

Also, the OPTIONS subsection dealing with -m output/format would be better readable, if the sentences starting with
-o "name=value[...name=value]"
-r resolution[,...,resolution]
-s {flipped|manual-tumble|normal|rotated}
-t type[,...,type]
-v
should get their own subsections.

BTW, both docs don't seem to be from a source file included in this repository. What is the original format? Is it Markdown, hosted somewhere else? And then converted to HTML and manpage format from that Markdown?

I wanted a recent build of Ipptool for a project I am working on - and target platform is Windows. Various factors led me to installing VC 2015 and building the source. This is definitely not my wheelhouse so what I wanted to contribute is a bit of developer experience going from no source to build exe.

1 - Install Bonjour SDK. I do not see it on the include or lib paths so is this on the default paths in VC somewhere?

2 - Install zlib. Perhaps adding a subproject referencing https://github.com/madler/zlib would do the trick. Again I needed to add this to the include and build paths everywhere. (And I just stumbled across NuGet which I suspect makes this process 10x easier)

3 - I had to remove the three "_pwgXXXX" entries from libcups2.def. The impression is that these are deprecated functions and I expect they are not used in the 3 executables of this project.

4 - It would be nice to have a build step that brings final resources together in one directory - the dll's and exe files.

I hope this feedback on the spots where I got stuck is of value to the project!

Jay

Hi Michael, Not sure if your interested but I was able to build ippsample on Windows 10 using the cygwin development environment, much to my surprise ;) I had to make some minor changes, mostly casts and a #define _GNU_SOURCE for a missing (non posix i guess) asprintf function.

It also appears to be running just fine, although I still have to run some tests.

Regards,

Daryl

Reference: https://appimage.org/

You should add support for an ippsample (or maybe just "ipp") AppImage that provides a "universal" Linux binary that can be built automagically via GitHub and Travis.

In addition to the usual AppImage.yaml stuff, you'll probalby want a configure option and stuff in the makefiles to have a configurable prefix so that the AppImage commands can be "ipp.server", "ipp.tool", etc. rather than "ipp.ippserver", etc.

:-)

Continuing to test ippserver functionality on a Raspberry Pi 3 (running openSUSE vLeap 42.3). Compiled on the Raspi itself from current sources (latest commit was Oct 12, cc48390).

Starting the most simple printer emulator command on the Rasp viai:

 ./server/ippserver -vvvv  "Test Test"

and then running ipptool from a different host:

 ./tools/ipptool -V 1.1 -t  http://leapraspi.local.:8000/ipp/print  examples/ipp-1.1.test

results in this output:

"examples/ipp-1.1.test":
   RFC 2911 section 3.1.1: Bad request-id value 0                       [PASS]
   RFC 2911 section 3.1.4: No Operation Attributes                      [PASS]
   RFC 2911 section 3.1.4: attributes-charset                           [PASS]
   RFC 2911 section 3.1.4: attributes-natural-language                  [PASS]
   RFC 2911 section 3.1.4: attributes-natural-language + attributes-cha [PASS]
   RFC 2911 section 3.1.4: attributes-charset + attributes-natural-lang [PASS]
   RFC 2911 section 3.1.8: Unsupported IPP version 0.0                  [PASS]
   RFC 2911 section 3.2: No printer-uri operation attribute             [PASS]
   RFC 2911 section 3.2.1: Print-Job Operation                          [FAIL]
       RECEIVED: 160 bytes in response
       status-code = client-error-attributes-or-values-not-supported (Unsupported document-format mimeMediaType value.)
       "document-format": Bad mimeMediaType value "" - bad characters (RFC 2911 section 4.1.9).
       EXPECTED: STATUS successful-ok (got client-error-attributes-or-values-not-supported)
       EXPECTED: STATUS client-error-document-format-not-supported (got 
       client-error-attributes-or-values-not-supported)
       EXPECTED: STATUS server-error-job-canceled (got client-error-attributes-or-values-not-supported)
       status-message="Unsupported document-format mimeMediaType value."
       EXPECTED: job-uri
       EXPECTED: job-id
       EXPECTED: job-state
       EXPECTED: job-state-reasons

Summary: 9 tests, 8 passed, 1 failed, 0 skipped
Score: 88%

The ipp-1.1.text file I used is from Git sources here, commit 442312b (2017, March 28th).

If you run ippserver with an appropriate configuration (sample configuration attached - unzip and run 'start-server.sh') and run the IPP Everywhere Self Certification test suite's "bonjour-tests.sh" script against it, test B-4 fails with the explanation 'Duplicate "notify-lease-duration-default" attribute in printer-attributes-tag group'.

Here is sample output:

neuromancer: sw-ippeveselfcert10-smitty [1662]$ ./bonjour-tests.sh 'IPP Everywhere Basic'
B-1. IPP Browse test: PASS
B-2. IPP TXT keys test: PASS
B-3. IPP Resolve test: PASS
B-4. IPP TXT values test: FAIL
"bonjour-value-tests.test":
Validate TXT record values using Get-Printer-Attributes [FAIL]
RECEIVED: 7149 bytes in response
status-code = successful-ok (successful-ok)
Duplicate "notify-lease-duration-default" attribute in printer-attributes-tag group
B-5. TLS tests: SKIP
B-5.1 HTTP Upgrade test: SKIP
B-5.2 IPPS Browse test: SKIP
B-5.3 IPPS TXT keys test: SKIP
B-5.4 IPPS Resolve test: SKIP
B-5.5 IPPS TXT values test: SKIP
Summary: 10 tests, 3 passed, 1 failed, 6 skipped
Score: 90%
ippserver-ipp-everywhere-basic.zip