🚀 go-pugleaf

> I can not find much info on DSC

The DSC specification is on
http://partners.adobe.com/asn/developer/pdfs/tn/5001.DSC_Spec.pdf

Bear in mind that DSC is only the format of wrapper comments in
PostScript. The comments in most cases don't do anything at all. They
accompany the actual PostScript code.

The way to get that actual code is typically from analysis of the PPD
file, since the code is completely specific to the printer. You will
want some background in PostScript programming to understand the
fragments in the PPD, but no amount of PostScript knowledge will let
you get by without the PPD.

Aandi Inston

Thanks for the reply. If DSC is only a comment and can not do anything of itself then I guess that is not what I am looking for.

Is the PPD the actual postscript file?

One of the things I am trying to accomplish- if I have a document with mostly static data and then an address block as the variable data. If I send this down as a unique page for each new address I have a huge file size. Would it be possible to structure a postscript file to read the static data only once and then read in the variable data.

Would I do this with the PPD file.

Thanks

>Thanks for the reply. If DSC is only a comment and can not do anything of itself then I guess that is not what I am looking for.

DSC is a comment. There exist "spoolers" - software that reads the DSC
comments and automatically inserts real code.  You would need to know
if you were using one of these.
>
>Is the PPD the actual postscript file?

No, the PPD is the Printer Description File. Search for *.PPD on your
hard disk to look for examples.

>Would it be possible to structure a postscript file to read the static data only once and then read in the variable data.

You could hand-code the PostScript to put the common information into
a procedure that you call over and over. It is rarely possible, or at
least simple, to adapt a pre-existing PostScript file to this usage.
>
>Would I do this with the PPD file.

No, the PPD file contains the information you need to control your
device, that's all.

Aandi Inston

Thanks,

I agree to handcoding being not an option.

Spoolers sounds like the way to go. We send directly to the printer which rips the file. Because the rip is not very fast, in some cases it can not drive the printer at rated engine speed. You can tell when the printing catches up to the spooling of the file, it all just slows down.

Is the spooler software something I can purchase third party or is this part of the printer software.

Thanks very much for your time

Jorge

Spoolers are typically found in complete workflow solutions. I've
never seen one offered as a separate utility. I think you will have to
write a PPD processor (which is essentially what the spooler would do
with the comments).

If you want to optimize printer performance, handcoding might be your
only option...

Aandi Inston

thanks, I will look further into what is entailed with PPD proccessor. In the meantime I have sent a note to Ricoh asking if they have spool software integrated in the device.

have a good day

Jorge P

Can I take a look at a sample file?

The DSC parser for a special class of documents can be as simple
as a sed script. The DSC comment can be replaced with a PostScript
procedure and the possibilities are endless.

BTW, does DOC1 check that the inserted fragment is actually a valid
DSC comment ? How about "%%FOO\n bar" ?

Alex Cherepanov
alexcher@coscript.com

Alex,

Doc1 does not validate the DSC input. They mention that dsc comments vary from manufacturer to manufacturer as the reason for this.

What is this SED script and how is it integrated with the postscript file. The idea of replacing the comment with a procedure is along the line of my thoughts.

Thanks for your input.

PS. I can create a sample file inserting some comments but doc1 inserts it exactly as you type including the %% characters, that is all.

Thanks

SED stands for STream Editor. It's an old UNIX program controlled
by a simple script language that changes the content of an
text file. Although sed is a minimal tool for the job, a simple
text tool can be written in any language: Perl, Python, C,
Intercal, Visual Basic.

We just need to replace the appropriate DSC comments with PS
procedures.

The exact implementation depends very much on the content of the
PS file and operation environment. It may be even possible to intercept the control from PS program using Idiom Recognition and run
the rest of the program through a procedure-based filter.

Alex Cherepanov
alexcher@coscript.com

Dong the find replace thing seems pretty cut and dry, I think I can handle that with a little testing.

I am not sure what you mean about intercepting control from PS program using idiom recogintion.

Thanks

      The documents are often printed in sorted order for postal carrier route.
      It would be nice to be able to pull from a designated paper tray




An easy way could be, to compare several PS-Files created by the printer driver. If you are on windows just take notepad and print test documents to your printer using the print to file flag.

      One of the things I am trying to accomplish- if I have a document with
      mostly static data and then an address block as the variable data.




If your printer has a file system may be it is able to hold a masterpage.

Norbert

Thanks Norbert,

Not sure what you mean by conmparing files on the sorted order thing. They are printed in sorted order just want to throw a different color page between trays for easier seperation. I think I found a workaround for this however. I can create some logic that will create a new page when tray changes. The page will be of different size and the printer should automatically pull from the correct paper tray. Our printer can do this without pause. Just mentioning that in case anyone else runs into this.

The printer has its own document server. If I send to the document server I can probably merge a couple of documents like you say. The only problem is sending to the document server is painfully slow, not sure why. To send a 10,000 page file would take all day.

Another way I just thought of is to make the common part into an image and attach it to a resource pack that Doc1 can create. In this manner I believe it only gets ripped once.

      Not sure what you mean by comparing files on the sorted order thing.




I thought you want to know the dsc which will pull from different trays. An easy way to understand the necessary dsc is to have a look how the printer driver handles this job.

      The printer has its own document server. If I send to the document server
      I can probably merge a couple of documents [...] is painfully not sure
      why. To send a 10,000 page file would take all day.




I'm not sure what your document server is.
In postscript it is possible to define a form (let's say master page) either temporarily or resistant depending on the printer.
For each page you just send the variable data and invoke the form.
If you install the form resistant it is up to you to send single pages or all pages in one job.

In postscript it is possible to define a form (let's say master page) either temporarily or resistant depending on the printer.

Where can I find information on achieving this: understanding the options of resistant and temporary and how to implement a master page and invoke it.

Thank you

jorgep,

I just reread your messages and realised that Aandi told you already "... could hand-code the PostScript to put the common information ..." and this would not an option for you. But creating and installing a form is a postsript programming task anyway.

So you better have a look into your printer manuals how to use and install a masterpage.

Hi Jorge,

Take the PostScript Language Reference Manual 'Third Edititon' and read carefully the 'Forms' chapter 4.7

Hope this helps,

(][ MaRC anToni
www.femfum.com
PostScript&PDF Tools Developers
Desenvolupadors d'Eines PostScript i PDF

Take the PostScript Language Reference Manual 'Third Edititon' and read carefully the 'Forms' chapter 4.7

Thanks, I will look into forms and master pages. My printers manual contains very little info and Ricoh has yet to respond.

It really surprises me how little control over the printer I have with postscript as opposed to pdf which allows me to actually open the properties window and set parameters plus use other functionality such as stapler and hole punch, though I still need to resolve this master page issue.

I wonder if anyone has done any testing with high res pdf to see if they rip any faster and if a master page is also possible with pdf's.

      It really surprises me how little control over the printer I have with
      postscript as opposed to pdf




Actually it's not the PDF which gives you more control over the printer, but the printer driver.
As you wrote you get your postscript from doc1, so you should blame this doc1-software, it gives you less control over the printer than the printer driver.

hmmm, that's interesting. We have postscript drivers on a true postscript printer.

I know doc1 adds a little extra code for post processing.

Are you saying that a typical postscript file when sent to print, say from ghost view, to postscript drivers has the option to open properties and access all the features of those drivers?

I can send a notepad file to the postscript printer and access those features so now you got me thinking, maybe I do need to put this question to Doc1.

Thanks

>Are you saying that a typical postscript file when sent to print, say from ghost view, to postscript drivers has the option to open properties and access all the features of those drivers?

In this case you aren't really using the driver. Drivers aren't
transformers of existing PostScript files, they are creators of new
ones.

The driver is used in this case only as a conduit, a way through the
printer. So you can expect most options to have no effect. This is not
a limitation of the driver, but of your workflow: the time to set
these options is when the PostScript is made. (Normally, of course,
this is the same time as you print).

Aandi Inston

Okay, I got it. Maybe I will just stick to converting the final postscript file to pdf with acrobat and when I have time investigate further options.

Im going to concentrate now on the common page merge with the variable data.

Thanks

jorgep,

For effecient Variable Data files, PostScript provides the Form Dictionary structure. This is a PostScript construct that allows you to put all of your static information for a page in a single "spot". Ideally, when the RIP first processes the "form", it caches it for reuse.

This way, all of your static data is 1) contained once in the file and 2) RIPped once. Your file will be smaller and process faster.

You'll need to learn PostScript programming for this, but don't let that stop you. Often the static data can be an EPS file that an artist can build for you in a program such as Illustrator or Corel Draw.

Let me know if I can be of further help.

Thomas D. Greer
www.tgreer.com

Thanks Thomas,

Using forms has been mentioned. I am going to read up on them as soon as I get a chance.

We have illustrator so I dont think it will be a problem creating the common part just need to know how to merge it, and I guess that is what forms are all about.

If you know of any tutorials on this let me know

Thanks again,

Jorge

I have written some articles on the topic, you can find them at <http://www.tgreer.com/resources.html>

Thomas D. Greer
 <http://www.tgreer.com>

Great articles, I read all 3 of them and have a much better understanding of what is going on though still not quite sure
how I would do this with our software.

I am going to refer our general manager to your web page. We may contact you by email to see if we can benefit from some
on site training geared to our specific needs, I could sure use it.

Thanks,

Jorge P.

There is a mistake that I haven't yet corrected in the SubFileDecode dictionary. It is missing a required key, /EODCount. It's a simple fix. My email address is on the website; I'm happy to help!

Thomas D. Greer
 <http://www.tgreer.com>