Empty pdf issue (partly) analyzed

[Magic48ges]

Hello 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

[Douglas Saltsman]

Originally Posted by Magic48ges

Hello 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'm with you on this, it's an installshield bug that slipped through apparently. I've since ditched Installshield and am working on a fix for everything mentioned.

Thanks for the feedback

[Flagranti013]

Please can you help me because I don't know what I did wrong.
If possible in German.

[joecool]

Hi Magic48ges,
thanks for your hints. It almost solved the empty pdf problem for me, except that I also had to correct two registry entries, as pointed out by another poster in this forum. See here for details: http://forums.primopdf.com/showthread.php?t=178