Magic48ges
10-05-2004, 05:50 PM
****o all,
I had the same problem as some of the other posters,
that Primo always created an empty pdf file.
After checking most of the other related articles in this forum,
and trying on my own workstations,
I came to the conclusion that either the executables and/or
some binary configuration file have 'C:\Program Files\...'
hardcoded somewhere inside.
Why?
For this I have to add some more info here,
a combination of experiences of other posters
and my own trials.
One problem seems to be the installer,
which installs the package to the virtual 'Program Files' folder
as directed by your system, and w/o chance to change the default target.
The target is read from your system's actual configuration,
so if you installed Windows on volume F:, and your default 'Program Files'
folder is called 'Programme' (dependent on Win localisation),
Primo will install to a subdirectory of 'F:\Programme\' .
Unfortunately the primopdf.ini doesn't get updated by the installer,
so the 'Command' and 'Arguments' keys always point to 'C:\Program Files' ...
Changing the key values of the ini file to point to the
actual installation drive and path doesn't change anything.
So far the only solution to get Primo working on my machines is
to create a 'Program Files' folder on the C: volume,
regardless if there is a Windows installation on C: ,
copying the whole ActivePDF tree to there,
and adjusting the target locations in the PrimoPort properties dialog,
which can be accessed from the printer port tab of the normal properties
dialog for a printer.
With 'Primo working' I mean that it creates a pdf with the wanted contents,
not only an empty pdf .
I'm using a German localisation of Windows, and so far the GS driver
of Primo hasn't been a problem. I did *not* need to use another PS driver.
So there's not much left but a maybe hardcoded reference
to 'C:\Program Files\...' , because all user adjustable paths
seem to be ignored by Primo.
However, Primo is a cool thing, exactly what I need right now.
Maybe the next version of Primo addresses the problems mentioned above,
and maybe there's a chance to have two other keys added to the ini,
namely 'DfltOutFile' (or alike), which would omit asking for a file name,
and 'DfltDPI', which would omit the need to interactively choose it;-)
Then it would be nearly perfect.
Regards
Magic48ges
I had the same problem as some of the other posters,
that Primo always created an empty pdf file.
After checking most of the other related articles in this forum,
and trying on my own workstations,
I came to the conclusion that either the executables and/or
some binary configuration file have 'C:\Program Files\...'
hardcoded somewhere inside.
Why?
For this I have to add some more info here,
a combination of experiences of other posters
and my own trials.
One problem seems to be the installer,
which installs the package to the virtual 'Program Files' folder
as directed by your system, and w/o chance to change the default target.
The target is read from your system's actual configuration,
so if you installed Windows on volume F:, and your default 'Program Files'
folder is called 'Programme' (dependent on Win localisation),
Primo will install to a subdirectory of 'F:\Programme\' .
Unfortunately the primopdf.ini doesn't get updated by the installer,
so the 'Command' and 'Arguments' keys always point to 'C:\Program Files' ...
Changing the key values of the ini file to point to the
actual installation drive and path doesn't change anything.
So far the only solution to get Primo working on my machines is
to create a 'Program Files' folder on the C: volume,
regardless if there is a Windows installation on C: ,
copying the whole ActivePDF tree to there,
and adjusting the target locations in the PrimoPort properties dialog,
which can be accessed from the printer port tab of the normal properties
dialog for a printer.
With 'Primo working' I mean that it creates a pdf with the wanted contents,
not only an empty pdf .
I'm using a German localisation of Windows, and so far the GS driver
of Primo hasn't been a problem. I did *not* need to use another PS driver.
So there's not much left but a maybe hardcoded reference
to 'C:\Program Files\...' , because all user adjustable paths
seem to be ignored by Primo.
However, Primo is a cool thing, exactly what I need right now.
Maybe the next version of Primo addresses the problems mentioned above,
and maybe there's a chance to have two other keys added to the ini,
namely 'DfltOutFile' (or alike), which would omit asking for a file name,
and 'DfltDPI', which would omit the need to interactively choose it;-)
Then it would be nearly perfect.
Regards
Magic48ges