> I've completed field filtering (only numbers allowed now) and bounds checking > in the MarginView class Great! > and fixed a bug that flipped the margin bottom and right > values when you set the page to Landscape. I've fix this small bug already, it's in CVS ;-) > I have also completed the saving of settings of the SetupMessage to > ~/config/settings/pdf=3D5Fwriter=3D5Fsettings for the PageSetupWindow and MarginView. I save : > > paper=3D5Frect > printable=3D5Frect > pdf=3D5Fcompatibility > orientation > pdf=3D5Fcompression > units Great! But... I guess we should follow the *undocumented* print queues settings policy: store them as attribute in the folder assign to this spooler. With a global settings, all print queues will share same settings, which forbidden user to create a "High Fidelity PDF rendering" queue and a "Quick & Small PDF rendering" queue. To see what I meen, create a new "test" print spooler/queue, and run this command from Terminal: listattr /boot/home/config/settings/printers/test You should get something like this: $ listattr /boot/home/config/settings/printers/test file /boot/home/config/settings/printers/test Type Size Name ---------- --------- ------------------------------- Text 8 Driver Name Text 5 Printer Name Text 5 state Text 5 transport Text 6 transport=5Faddress Text 6 connection Text 16 Comments MIME str 29 BEOS:TYPE We could store our PDFWriter specific settings into a single PDFWriter:settings attribute, as a BMessage (which should be easer from the current BMessage runtime storage. We could also store them separatly in many PDFWriter:paper=5Frect, etc, but... well, why bother!=3F ;-) > Before I commit this though, I have a question about the other settings you > wanted to save, in the JobSetupWindow class=3D3F I forget what your last message > said. I would like to add the embebded/not embebded fonts list later. > I also want to add a new class, PDFWriterSettings, that does all the work of > loading and saving the settings. Right now all this code is in the > PageSetupWindow class and if JobSetupWindow needs it then it should be in a seperate > class. Yep, this would be a good idea, it'll will help isolate the storing policy from others modules... Philippe -- Fortune Cookie Says: Swipple's Rule of Order: He who shouts the loudest has the floor.