FreeLists / open-beos-printing / [open-beos-printing] Re: Spool File Format?

[Philippe Houdoin <philippe.houdoin@xxxxxxx>]

> for the implementation of BPrintJob the spool file
> format has to be known. Below follows what I have
> discovered yet by looking at the PDF Writer source. 
> It also includes questions under C++ line comment.
> Please help to fill the gaps.

Once, I found on a Japanese web site this image:
http://philippe.houdoin.free.fr/phil/beos/pdf_writer/spool_file_format_for_R4.pn
g

Maybe it could help a little.

Something we don't know is who create the job file?
print_server? BPrintJob?
In last case, how BPrintJob knows

> Spool File Format
> Filename: Description@8DigitNumber  // time/date/uptime?

I guess it's something based on system_time(), yes.
Hence the @ separator...

> Location: /boot/home/config/settings/printers/PRINTER/
> File Contents
> 
> struct print_file_header {
>        int32   version; // host byte order; minor: version & 0xffff; 
>                         // major: version >> 16
>        int32   page_count;
>        off_t   first_page; // always -1?

Maybe this offset was there for future header struct evolution, so that 
one can jump directly at the first page block, that is without having to 
unflatten the BMessage...

       int32   _reserved_3_;
       int32   _reserved_4_;
       int32   _reserved_5_;
};

> Flattened BMessage JobMessage {
>     // what fields are required, which type do they have, what meaning (if 
> not obvious)?

Well, as this flattened BMessage is inited by BPrintJob() and then fill up by 
driver's config_page() and last completed by driver's config_job(), it's hard 
to see the fields BPrintJop() set himself.

Maybe by tweaking a pseudo-print-driver so that he don't add any specific field 
in config_page() and config_job(), then calling PrintToStream() on the message 
he read from spool file will dump it.

I don't know if his content is the same than the one passed in take_job(), but 
I'll bet it!

> page_count times {
>       uint32 pictureCount;
>       pictureCount times {
>            // meaning/type of unknown?
>               byte unknown[40+sizeof(off_t)];

In fact, according, first come a single off_t next_seek_position;, then byte 
reserved[40];
The offset next_seek_position may help point to next picture info block, 
without having to unflatten this picture info block Bpicture, like first_page 
field in the print_file_header...

> CSTR _spool/Status 
>    // other states?
>       Processing

"Waiting", set by BPrintJob when it's fully written.
"Error", set by print_server if driver failed

There is no "Done" status AFAIK, as print_server delete it in this case...

Take a look at these BeNewsletter articles for some inside look at print_server 
code:
http://www.beatjapan.org/mirror/www.be.com/aboutbe/benewsletter/volume_II/Issue1
.html#Insight2
http://www.beatjapan.org/mirror/www.be.com/aboutbe/benewsletter/Issue64.html#Ins
ight

For full binary compatibily with R5 spool file format, we should look at 
all available print_server addons to see what BMessage fields name and 
attributes names they rely on... or ask BinkJet author's help on this subject.

-Philippe