REQ: Print in WinUAE -improovements

[Borg_Number_One]

In reference to the thread: NEWS: Print in WinUAE ; Print with WinUAE and the page: printing in WinUAE - three methods here is a further suggestion:

To avoid to do anything(Press F12 and change the printer) in the WinUAE-GUI to reach to complete any PrintJob a further clickbox would be great which detects the postscript and its commands.


If the command:

"end.." (= 656E640A04 HEX)

or just the command

".." (= 0A04 HEX )

pass through the emulated parallel
port(and then the selected printer) WinUAE should automatically do the same
like:
"changing the current printer to another/no printer"
would effect.

You can compare all the files in the attachement and you can see that each file ends with:
"end.." (= 656E640A04 HEX) or just with ".." (= 0A04 HEX ).
So the detection (with the help of a clickbox) of that mentioned bytes to
drive a printer-change to another or none printer and back to the previous
printer is a really good idea.

Together with "method three" on my page this would be a really good solution
to print.


PS: change the printer and "flush the printjob" is currently not the same.
"flush the printjob" does not really work...

[Borg_Number_One]

Originally Posted by Toni Wilen

> Compare all the files in the attachement and you can see that each file ends
> with: "end.." (= 656E640A04 HEX) or just with ".." (= 0A04 HEX ).
> So the detection (with the help of a clickbox) of that mentioned Bytes to
> drive a printer-change to another or none printer and back to the previous
> printer is a really good idea.

I was thinking about this and what about "hooking" parallel.device (does
all printer programs use parallel.device or is there programs that poke
the parport hardware directly?) open/close calls to detect when to flush
the buffer? I think it would be possible to do this automatically
without need for any Amiga-side program.

(I believe/ or it seems to be)The current ParallelPort-Emulation is 100%.
This should not be changend in: "...automatically way..." as far as it does not decrease the current 100% compatibility.
If it would decrease the compatibility then the user should have the possibility to enable/disable(...KlickBoxes rules... ) the detection of
a.)the "postscript end bytes"(by the data produced by the PostScriptPrinter)
and/or
b.)the "open/close calls".

A friend has some or some more drawing and writing programs which can use their own PostScript driver and so it could be that the end of the data stream(print job) looks different to the PostScript Printer(and its produced data) in AmigaOS/Workbench.

I will ask him if he can produce the raw-files again...
If the "postscript data ends" by the mentioned programs look different then WinUAE-side should detect some more strings of bytes too

Remind:
Change the printer and "flush the printjob" is currently not the same.
"flush the printjob" does not really work...change the printer works better.

[Toni Wilen]

I don't think it causes any compatibility problems. No printer selected or direct parport emulation enabled = no hacks needed. And I don't believe there are programs that print part of print job, close parallel.device, reopen it and print next part...

And printing isn't 100% compatible anyway

[Borg_Number_One]

...something goes wrong here...
No parallel-port emulation????
How to realize the mentioned PostScript-methods then?

[Toni Wilen]

"direct parallel port emulation" = emulated parallel port is "routed" to PC hardware parallel port, paraport.dll required.

Parallel port list shows LPT0 etc.. if paraport.dll is installed. Unfortunately this isn't perfect because PC parallel port isn't as flexible as Amiga parport. (and interrupt is not emulated yet)

[Borg_Number_One]

Well, which mode do you want to use now for the detection?
The method with paraport.dll is not really good, I think.
You cannot choose the printer which use the redirection.
So all the methods cannot be realized.

My suggestion:
Just insert a small clickbox with:
"enable AmigaOS/Workbench Postscript Printer detection"
or
"AmigaOS/Workbench PS Printer support"
[QuickInfo: If enabled and "PostScript Printer Driver" in AmigaOS/Workbench is used, then WinUAE detects each print job on Amiga-side and automatically finishes the print jobs on WindowsSide.

[Toni Wilen]

Ignore the paraport.dll, it has nothing to do with this problem.

I think your solution is too complex, imho WinUAE should do the PS->Windows printer conversion transparently and automatically. Maybe there is some kind of "Postscript"-plugin?


1: Copy the plugin to WinUAE's directory
2: Tick "Enable Postscript-printer emulation"-checkbox
3: Adjust Amiga printer preferences
4: Print!

[Toni Wilen]

Maybe there is some kind of "Postscript"-plugin?

Yes! (I know I am replying to myself..)

Ghostscript comes with gsdll32.dll which can be used for example to print PostScript documents transparently.

I think this is the perfect solution for WinUAE printing problems.

[Borg_Number_One]

Originally Posted by Toni Wilen

I think this is the perfect solution for WinUAE printing problems.

No.

Your current method is just a beginning.

After printing anything in AmigaOS/Workbench there appears a Win32GUI(by GhostScript) which want to know which printer will be used.
That means the emulation is forced to do a break.

This method is not good and would not solve the problem:
"do not do anything on Windows-Side after print job on Amiga-Side".

Remind, in a good userfriendly program the user should have the possibility to decide about (nearly) everything everytime.

My methods (which drived you into the whole print automation problem )
seems to be better:

The user can decide which printer has the redirection to Redmon+Ghostscript (Windows Printer Settings).
Furthermore the user can decide in WinUAE which printer(that has the redirection) will be used.

If you are able to automise my methods (espacially method 3) then it is the final solution.
And then the problem: "do not do anything on Windows-Side after print job on Amiga-Side" is solved.

Furthermore I tried to print the "ReadMe OS3.5.guide".
Your current method takes tooooooooo long and reduce the whole cpu-power after and before select a printer in "GhostScript's Choose-Printer-Dialog".

My Method is reaaaaally fast and it is silent, because the redirector/printer is allready choosed which converts the PostScript-Data-Stream to normal "DIB"-Format and prints it to choosed printer(-sOutputFile="%printer%printer_name").

Well, it would be less work for you to just insert a switchable PostScript-Detection + linked automatically "flush print jub".

Furthermore you can use the printer variable from WinUAE-GUI to fill the printer variable in GhostScript to avoid the dialog-screen: "Choose your Printer".

"flush print jub" seems to be the same like "change printer" now.
It works fine now.

[Toni Wilen]

I am quite sure all dialogs can be removed (gsdll32.dll really is the main Ghostscript engine that all GS-programs use), I just didn't bother with it yet..

Also whole parsing and printing process can be moved to separate background process (printing will 100% in background)

btw, Redmon's installation and setup was really confusing, I don't want to "force" users to do that

btw2, what about users with real PostScript-compatible printer? Do they need separate PS-start/end-detection option without the emulation?

[Borg_Number_One]

Originally Posted by Toni Wilen

Hi, I think this fixes most/all PS-printing problems..

- uses selected printer from GUI
- no dialogs
- background printing
- separate PS-detection without emulation

Your current WinUAE has two klickboxes:
"PostScript Printer Emulation"
"PostScript detection"
Why???
I am cunfused...what do you make with my idea(s)???

Well, there still seems to be a bug...
It takes tooooooooooo long but it works.
(both switches has to be activated.)
Could it be that you use a higher dpi while converting PS-Data to DIB(-sDEVICE=mswinpr2 -sOutputFile="%printer%printer name") than normal(300dpi)?

This is a good point to insert a pulldown menu to select the dpi which will be used for conversation:
PS-to->[-sDEVICE=mswinpr2 -sOutputFile="%printer%printer name"].


It seems to be that my suggestion works:
The printer (variable) which is selected in WinUAE-GUI fills the same printer variable in GhostScript while using "GhostScript printer emulation".

For development reasons insert a clickbox to enable/disable the progress bar.
(enable/disable "-dNoCancel")

WinUAE only should detect PostScript-Data-Stream, if its end then WinUAE should automatically flush the print job(clean the parallel-port buffer) and prints the PostScript-Data with the help of "GhostScript" to the selected printer in WinUAE-GUI.

Well, if there is a real PostScript-Printer connected and selected(many new LaserPrinter "understand" PostScript) , the "GhostScript-method/way" would be useless.
"Post Script Detection" is it the same like "PostScript Printer Emulation" without Print the PostScript with the help of GhostScript?
Does it just automise the data-stream and flush printer job if PostScript-Data-Stream ends?

If just "PostScript Detection" is enabled, what happens while printing?
In theory this mode does not use any GhostScript library and it just should look for the end of the PostScript-Data-Stream and Flush the printer job if the PostScript-Data-Stream-end-bytes passed....in theory.

However try following.

Open any Workbench/AmigaOS WinUAE-preset and choose only "PostScript Detection" then run editpad and print to any printer which uses my method and the redirection monitor or to a real PostScript printer.

You will see that in Windows Printerjobs appears an entry but nothing happens.
It seems to be that detection of the PostScript-Data-Stream-end-bytes
does not work, if only "PostScript Detection" is choosed.
So the printjob will not be flushed automatically.

[Toni Wilen]

For development reasons insert a clickbox to enable/disable the progress bar.

Ok. Maybe even textbox that can be used to set "advanced" GS parameters?

It takes tooooooooooo long but it works.

Printing thread uses slightly lower priority than main WinUAE. PS processing needs lots of CPU power and imho slightly slower printing is better than emulation slowing down and crappy sound.

Make sure "CPU Idle" in CPU panel isn't at leftmost position.

"Post Script Detection" is it the same like "PostScript Printer Emulation" without Print the PostScript with the help of GhostScript?
Does it just automise the data-stream and flush printer job if PostScript-Data-Stream ends?

Yes but it seems to be broken. Not surprising because I didn't test it yet


To anyone else reading this: Direct PostScript support means printing is now possible with any Windows-supported printer. You only need to install Ghostscript, tick "PostScript printer emulation" in WinUAE options and use Amiga PostScript printer driver.

Direct ghostscript-support isn't yet publically available.

[Borg_Number_One]

Originally Posted by Toni Wilen

To anyone else reading this: Direct PostScript support means printing is now possible with any Windows-supported printer. You only need to install Ghostscript, tick "PostScript printer emulation" in WinUAE options and use Amiga PostScript printer driver.

No, that is not correct.

It seems to be that you do not really understand the whole "printing thing".
The whole time since WinUAE has Parallel-Port Emulation it supports
real PostScript-printer if in AmigaOS/Workbench the PostScript printer was/is selected.

If you have a real PostSript compatible Printer then it understand the PostScript-Data-Stream which comes from AmigOS/Workbench's PostScript Printer.
In this case and if only "PostScript detection" is selected then WinUAE only should detect when PostScript ends and then it just flushs the print job; it must not use "GhostScript" in this case too!!!
(Maybe if the real PostScript-Printer only supports a higher version of PostScript than AmigaOS/Workbench's PostScript Printer-driver could produce then there should be insert a third clickbox.
This clickbox should detect the end of the PostScript-Data-Stream, flush the printjob, should convert/store/save the PostScript temporary file to a higher version of PostScript then it should send it to the selected Printer.)

The correct news is that my idea to automise the "flush print job" with the help of PostScript-End-Of-File/Stream-detection is addad to WinUAE.

GhostScript is only for convert PostScript data to DIB-data to print the stuff to/on any real printer.

[Toni Wilen]

Originally Posted by Borg_Number_One

No, that is not correct.

It seems to be that you do not really understand the whole "printing thing".
The whole time since WinUAE has Parallel-Port Emulation it supports
real PostScript-printer if in AmigaOS/Workbench the PostScript printer was/is selected.

Huh? Maybe it was you who didn't understand..

"Postscript detection" = automatic print job flush (detects PostScript start and end), Ghostscript is not used -> for real Postscript printers. (This works in old UAE versions but flushing was not automatic)

"Postscript emulation" = use Ghostscript and detect start and end -> for non-PostScript Windows printers with automatic flush. (most users)

[Borg_Number_One]

Originally Posted by Toni Wilen

]Huh? Maybe it was you who didn't understand..

"Postscript detection" = automatic print job flush (detects PostScript start and end), Ghostscript is not used -> for real Postscript printers. (This works in old UAE versions but flushing was not automatic)

"Postscript emulation" = use Ghostscript and detect start and end -> for non-PostScript Windows printers with automatic flush. (most users)

I know that.

Originally Posted by Toni Wilen

Direct PostScript support means printing is now possible with any Windows-supported printer.

The whole time WinUAE supports PostScript-Printer, but without automatic detection of PostScript and flush print job.
That just was what I mean with: "...not true...".

Well, here are some translations/suggestions:

PostScript printer emulation->PostScript-Druckeremulation
PostScript detection->PostScript-Erkennung


Quickinfo[PostScript printer emulation]:

This is allows you/enables to print on any selected printer. Condition is to use PostScript printer driver in your Amiga-Apps. An installation of "GhostScript" (C) and an availability of "gsdll32.dll" in your WinUAE-directory is necessary.
->Dies ermöglicht es auf jedem Drucker zu drucken.
Vorraussetzung ist die Verwendung eine PostScript-Druckertreiber in Amiga-Anwendungen.
Eine Installation von "GhostScript" und das vorliegen der Datei: "gsdll32.dll" im WinUAE-Verzeichnis ist notwendig.

Quickinfo[PostScript detection]:

If enabled, WinUAE checks the emulated parallelport for/to the end of a PostScript-PrintJob of/by an Amiga-Appliacation and do automatic flush of the print job.
->
WinUAE überprüft den emulierten Parallelport auf das Ende eines PostScript-Druckauftrages einer Amiga-Anwendung und entleert dannach den Druckauftrag automatisch.

CPU-idle method you mentioned works. I do not know why I did forget this slider.

[Borg_Number_One]

Excuse me for that late reply.
It tooks much time to test all the things and write this.

Originally Posted by Toni Wilen

PS detection fixed and parameter textbox added (but note that you can't,
at least not yet, disable -dNoCancel because WinUAE uses it internally.
anyway, check winuaelog.txt if you want to see more info..)

Wooooooooooooooooooooooooooooooooooooooooooooooooooooooooow ,
it is reeaaaaally fast, "PostScript Detection" works reaaaally great and Ghostview opens really fast too.
(I used mode 2 of CPU idle [1 2 3 ... 11], the first printer + "PostScript detection")

You should know I use following windows printer settings to test WinUAE:

1.)
"Any Printer"->Redmon(Redirection Monitor)Port RPT1: ->RPT1 properties:[Arguments]=C:\Programme\Ghostgum\gsview\gsview32.exe %1

2.)
"Any Printer"->Redmon(Redirection Monitor)Port RPT2: ->RPT2 properties:[Arguments]=C:\Programme\gs\gs8.14\bin\gswin32c.exe -sDEVICE=mswinpr2 -sOutputFile="%printer%FinePrint" -dNoCancel %1

3.)FinePrint virtaul printer(it is really great to test different Print settings together with winuae without any real paper; it shows you the printout.)


Well now the bad news:


If I just use "PostScript detection" + "Any Printer"(which use RPT2: ) in WinUAE then GhostScript prints to FinePrint and it opens very fast and FinePrint shows the print out.

If I use "PostScript printer emulation" + "FinePrint"-printer and print "test" from "editpad" it does not happen anything.
(fpdisp5a.exe->Fineprint uses 99% of CPU)
I tried with a real printer directly and it works.
I see that the size of print job is 91 MB...it seems to be DIB-data of one DIN A4 but which dpi do you currently use to print via "gsdll32.dll"?.
(none -> the standard one: 300dpi?)

I have to choose another printer or flush the print job before any thing happens and "Fineprint" opens.


...it is funny... now to print to "FinePrint"-printer directly with enabled "PostScript printer emulation" does not work or takes tooooo long.
This could happen with other printers too.

Possible solution:
Furthermore I tried some priority settings in Win2K task manager between winuae and fpdisp5a.exe...then you could say it works a little.
It seems to be that WinUAE has to use a lower priority to print with Fineprint.
...yes try more CPU-idle and choose lower priority then fineprint works too.
Pleasy try the mentioned methods too & get FinePrint here:
www.fineprint.com.


Furthermore it would be great if enable/disable "PostScript detection" and/or "PostScript printer emulation" while emulation would work.

Originally Posted by Toni Wilen

btw, location of gs32dll.dll is now autodetected if Ghostscript is
properly installed, there is no need to copy the dll to WinUAE's
directory anymore.

[STRIKE]gs32dll.dll[/STRIKE] -> gsdll32.dll !
...yes that was the first which makes me a little "angry" when I heared: "put gsdll32.dll to winuae-dir"
Good job.
This will result that the quickinfo will be smaller too

You should insert an autodetection of "ParaPort.dll" too.