Skip to main content
Hi everyone,

This is not a question, but a transcription of a private message exchange  to maybe help other people.

Following the installation of a Ghostscript PDF printer, as discussed here, I asked this question to Gianni Sandigliano who was kind enough to answer :

Me :


Hi Gianni.

Sorry to bother you directly, but I have a question regarding your 2018 post about Ghostscript PDF.

I've installed GS PDF and the multi file port system, I can print where I want using the instance name, so far so good.

But I need to send the PDF file generated by mail, so I have to be sure the process is over.

.../...

You say :
syncronization between the two subsystems (your Uniface application and spooling subsystem) is up to you and could be implemented in many different ways.

It "seems" that the PDF file size stays 0 until it's over, but is it always true ? Is there a DCOM ? Is there a way to test if the Multi file port is active (but then what happens if several users print at the same time, we are on a TSE server)

.../...

His answer :


Ciao Jean-Marc,

Yes, the printing subsystem is asyncronous so you need to wait until the PDF file is completed before being able to apply a whatever post-processing.
Ghostscript is involved here to convert PS to PDF at the end of the printing process; being a multiplatform software package does NOT support COM/DCOM.

IMHO you have at least 2 choices to properly syncronize:
1) Use the command you've defined in MultiFilePortSystem to give back a signal to your waiting application, like generating a specific file.
2) In a whatever way checks system locks on output file your application is waiting for.

I've seen both working in different implementations at different Uniface sites.

The simple way is try to fileload/raw the PDF you are expecting into a dummy variable.
Until the file is generating you will get a $status less than 0; when you are getting $status more than 0 the file is complete and you can clean your dummy variable and go on with your application functionality.

I hope this help you to complete your job!

Gianni


So thanks to him again and I hope it will help other people too.

------------------------------
Jean-Marc SALIS
Rocket Forum Shared Account
------------------------------
Hi everyone,

This is not a question, but a transcription of a private message exchange  to maybe help other people.

Following the installation of a Ghostscript PDF printer, as discussed here, I asked this question to Gianni Sandigliano who was kind enough to answer :

Me :


Hi Gianni.

Sorry to bother you directly, but I have a question regarding your 2018 post about Ghostscript PDF.

I've installed GS PDF and the multi file port system, I can print where I want using the instance name, so far so good.

But I need to send the PDF file generated by mail, so I have to be sure the process is over.

.../...

You say :
syncronization between the two subsystems (your Uniface application and spooling subsystem) is up to you and could be implemented in many different ways.

It "seems" that the PDF file size stays 0 until it's over, but is it always true ? Is there a DCOM ? Is there a way to test if the Multi file port is active (but then what happens if several users print at the same time, we are on a TSE server)

.../...

His answer :


Ciao Jean-Marc,

Yes, the printing subsystem is asyncronous so you need to wait until the PDF file is completed before being able to apply a whatever post-processing.
Ghostscript is involved here to convert PS to PDF at the end of the printing process; being a multiplatform software package does NOT support COM/DCOM.

IMHO you have at least 2 choices to properly syncronize:
1) Use the command you've defined in MultiFilePortSystem to give back a signal to your waiting application, like generating a specific file.
2) In a whatever way checks system locks on output file your application is waiting for.

I've seen both working in different implementations at different Uniface sites.

The simple way is try to fileload/raw the PDF you are expecting into a dummy variable.
Until the file is generating you will get a $status less than 0; when you are getting $status more than 0 the file is complete and you can clean your dummy variable and go on with your application functionality.

I hope this help you to complete your job!

Gianni


So thanks to him again and I hope it will help other people too.

------------------------------
Jean-Marc SALIS
Rocket Forum Shared Account
------------------------------
Thanks for sharing this info. Appreciated.

------------------------------
Daniel Iseli
Principal Technical Support Engineer
Uniface Services
Rocket Software, Switzerland
------------------------------
Hi everyone,

This is not a question, but a transcription of a private message exchange  to maybe help other people.

Following the installation of a Ghostscript PDF printer, as discussed here, I asked this question to Gianni Sandigliano who was kind enough to answer :

Me :


Hi Gianni.

Sorry to bother you directly, but I have a question regarding your 2018 post about Ghostscript PDF.

I've installed GS PDF and the multi file port system, I can print where I want using the instance name, so far so good.

But I need to send the PDF file generated by mail, so I have to be sure the process is over.

.../...

You say :
syncronization between the two subsystems (your Uniface application and spooling subsystem) is up to you and could be implemented in many different ways.

It "seems" that the PDF file size stays 0 until it's over, but is it always true ? Is there a DCOM ? Is there a way to test if the Multi file port is active (but then what happens if several users print at the same time, we are on a TSE server)

.../...

His answer :


Ciao Jean-Marc,

Yes, the printing subsystem is asyncronous so you need to wait until the PDF file is completed before being able to apply a whatever post-processing.
Ghostscript is involved here to convert PS to PDF at the end of the printing process; being a multiplatform software package does NOT support COM/DCOM.

IMHO you have at least 2 choices to properly syncronize:
1) Use the command you've defined in MultiFilePortSystem to give back a signal to your waiting application, like generating a specific file.
2) In a whatever way checks system locks on output file your application is waiting for.

I've seen both working in different implementations at different Uniface sites.

The simple way is try to fileload/raw the PDF you are expecting into a dummy variable.
Until the file is generating you will get a $status less than 0; when you are getting $status more than 0 the file is complete and you can clean your dummy variable and go on with your application functionality.

I hope this help you to complete your job!

Gianni


So thanks to him again and I hope it will help other people too.

------------------------------
Jean-Marc SALIS
Rocket Forum Shared Account
------------------------------
I used the method of waiting for the ghost script process to be over, but I had to ask myself "what does that mean?" since it's a separate asynchronous process I didn't know how long to wait so I thought I would use the task manager to tell me when it was done. Here's a quick snippet if anyone is interested.

commandin = "tasklist /FI %%"IMAGENAME eq gswin32c.exe%%""
count = 0
repeat
if ($lfileexists("c:\\temp\\print.pdf") = 1) break
message/nobeep "Print pending....please wait (G:%%count%%%)."
sleep 100
count += 1
activate "oscommand".commandout(commandin,commandout)
scan commandout,"PID"
until ($result = 0 | count > 10)

------------------------------
Adkins Larry
Proware
Cincinnati OH United States
------------------------------
I used the method of waiting for the ghost script process to be over, but I had to ask myself "what does that mean?" since it's a separate asynchronous process I didn't know how long to wait so I thought I would use the task manager to tell me when it was done. Here's a quick snippet if anyone is interested.

commandin = "tasklist /FI %%"IMAGENAME eq gswin32c.exe%%""
count = 0
repeat
if ($lfileexists("c:\\temp\\print.pdf") = 1) break
message/nobeep "Print pending....please wait (G:%%count%%%)."
sleep 100
count += 1
activate "oscommand".commandout(commandin,commandout)
scan commandout,"PID"
until ($result = 0 | count > 10)

------------------------------
Adkins Larry
Proware
Cincinnati OH United States
------------------------------
i remember the same problem firing pdfwriter, while pdfwriter is building the pdf, it's not there yet, the trick check of the file is build, (prefarable use a guid for naming this file), then when finisched, rename it to the outputfile of your choice.

------------------------------
Dino Seelig
Tcco
Drunen NL
------------------------------
i remember the same problem firing pdfwriter, while pdfwriter is building the pdf, it's not there yet, the trick check of the file is build, (prefarable use a guid for naming this file), then when finisched, rename it to the outputfile of your choice.

------------------------------
Dino Seelig
Tcco
Drunen NL
------------------------------
With PDFWriter you've got (had ?) a DCOM object which you can communicate with to know the status of the printing (that's the method we use with it)

------------------------------
Jean-Marc SALIS
Rocket Forum Shared Account
------------------------------