Apologies, but bugs in FOP 0.20.5 will no longer be fixed. 
Please try FOP 0.93 or the Trunk, and see if the problem persists there.

I have clients that are using PDF's I write programmatically in my application. 

Now I acknowledge that this could be a problem with the third party API i use, 
but though I would see if anyone here has had this problem. 

basically they will get PDF's of orders created in a system. 

These orders will arrive one by one as email attachements. 

The administrators, in this case, will print all the orders that come in at a 
time. 

In each run 25-30% of them will print incorrectly. They appear on the screen 
exactly as they should. 

When they print the incorrect ones print with a character shift. b for a, c for 
b 

so 'Your Order' will print as 'Zpvs%Psefs'. The formatting of the text, and 
layout on the page is all as it should be. 

Now if you printed any of these documents again, they would print as they 
should. This meaning the same document, from the same email, printed again. 


Notes : 
- the problem is quite hard to reproduce : if you re-open the same file and 
print it again, or relaunch the same editing process, 
  there is no problem ! 

- the bug occurs when using PCL laser printers (mostly HP printers) 
  and Inkjet printers. 
  When using PostScript driver, it's ok. 
  (but we don't want to use PS drivers, it's slower and increase memory usage 
on the printer) 

- in the previous version of our application, 
  the silent printing system used AWT instead of Acrobat Reader, 
  at that time, there was no problem. 

- our pdf documents do not use embedded fonts.

- the problem is reproducable on old Acrobat RReader versions as well as on the 
latest.

Problem still exitsts within current version 0.94.

See some more hints to the problem...

This is a mis-feature of (some?) Windows print drivers. They: 
1) send font sub-sets to the printer, but, rather than sending the characters 
with their proper encoding, use a custom encoding that allocates codes in order 
of appearence - not sending the proper codes is a bug and will break the 
document for use on the Palm. 

2) if there is a font substitution available for the printer, they may then 
fail to actually use (or even send?) the font subset and try and use the 
substituted font in its proper encoding for the bogus encoding created in 
producing the subset

Unless you take the necessary steps to rule out the third-party APIs for being
responsible for this and you supply concrete examples (or a guide) to reproduce
the problem, there's really nothing we can do. There are most probably a lot of
variables in here that we don't know of.

You say it works with some printer drivers and not with others. That's an
indication that FOP is not at fault. Furthermore: so many people are printing
FOP-generated PDFs with Acrobat and don't have problems. You'd have to look more
towards the end of the processing chain, i.e. between Acrobat and the operating
system, where we can't help you. Unfortunately, Adobe usually leaves you in the
rain when you run into problems and printer drivers are often the source of
problems in that area.

Hi!
Well, due to the fact that the problem occurs only very arbitrary the problem 
might affect a bigger number of people than you think. But nevertheless the 
problem is discussed in sseveral other groups. To give you an idea here some 
links

http://www.adobeforums.com/webx/.3bbeb93b -> this content has been extracted by 
myself
http://www.adobeforums.com/webx/.3bc3a663
http://www.adobeforums.com/webx/.3bc2f70f

http://www.hostingforum.ca/156897-garbled-output-character-shift-adobe-pdfs-via-
citrix.html

Of course it is not possible for me to rule out third party issues. All I can 
say is that the problem occurs only with documents generated by FOP. And I 
aggree as long as there is no way of reproducing the problem, it is quite hart 
(or maybe impossible) to track down the problem. Nevertheless in my opinion you 
should not ignore this error. Maybe there is a problem with the font 
identification mechanism inside the generated PDF documents.

(In reply to comment #4)
> Unless you take the necessary steps to rule out the third-party APIs for being
> responsible for this and you supply concrete examples (or a guide) to 
reproduce
> the problem, there's really nothing we can do. There are most probably a lot 
of
> variables in here that we don't know of.
> You say it works with some printer drivers and not with others. That's an
> indication that FOP is not at fault. Furthermore: so many people are printing
> FOP-generated PDFs with Acrobat and don't have problems. You'd have to look 
more
> towards the end of the processing chain, i.e. between Acrobat and the 
operating
> system, where we can't help you. Unfortunately, Adobe usually leaves you in 
the
> rain when you run into problems and printer drivers are often the source of
> problems in that area.

Ulrich, the links you provided clearly indicate that the problem must be in
Acrobat Reader (or maybe in the Acrobat Reader/Printer Driver interaction). If a
PDF file displays correctly on screen but prints wrong, how can FOP be the cause
of that? Furthermore, people report that opening the same file again usually
makes the problem go away. The only thing we can potentially do in FOP is add an
FAQ entry giving pointers about the problem. But otherwise, it's completely up
to Adobe (or you switching to a different PDF viewer).
Maybe something in FOP causes this bug in Acrobat to appear but without Adobe
making a statement what exactly that is (if there is something in the first
place), there's nothing we can do.

BTW, are you in a Citrix environment? I've seen all sorts of weird behaviour
around printing on Citrix clients in my career.

Sorry, but I have no idea how I could help here. Let's leave this open for the
moment. If we get more information from Adobe, maybe we can do something in
terms of documentation.

The system I use is native (no VM-Ware) Windows (2000, XP, Vista) and the 
problem occurs on all three of them.

Thanks for your help.

(In reply to comment #6)
> Ulrich, the links you provided clearly indicate that the problem must be in
> Acrobat Reader (or maybe in the Acrobat Reader/Printer Driver interaction). 
If a
> PDF file displays correctly on screen but prints wrong, how can FOP be the 
cause
> of that? Furthermore, people report that opening the same file again usually
> makes the problem go away. The only thing we can potentially do in FOP is add 
an
> FAQ entry giving pointers about the problem. But otherwise, it's completely up
> to Adobe (or you switching to a different PDF viewer).
> Maybe something in FOP causes this bug in Acrobat to appear but without Adobe
> making a statement what exactly that is (if there is something in the first
> place), there's nothing we can do.
> BTW, are you in a Citrix environment? I've seen all sorts of weird behaviour
> around printing on Citrix clients in my career.
> Sorry, but I have no idea how I could help here. Let's leave this open for the
> moment. If we get more information from Adobe, maybe we can do something in
> terms of documentation.

I got some mor information today. It seems as if the problem mainly occurs 
under the following circumstances:
1) XML is generated
2) XML is transformed using XSL-FO and FOP called via JavaScript
3) immediately after the transformation the PDF is shown using a JavaScript-Call
4) if you print now the error may occur

Is it possible that on a slow machine, the pdf file is not completely written 
(buffer not completely emptied) while the FOP process signals the system it is 
ready and now acrobat opens a file where e.g. some crucial font information at 
the end of the file is not available, yet? When you open the file a second time 
the file is complete and therefore one can print it...

I know the description above sounds quite unlikely but if one takes into 
account that the problem occurs quite rarely and is not reproducable with the 
same generated document, maybe its possible.

The source for step two and three is attached below.


The source for step 2 and 3:
// create an ActiveXObject and declare some general stuff
var aShell = new ActiveXObject("WScript.Shell");

var sPathRoot  = window.top.BTMDB.RootURL + "pdf";
var sPathFOP   = sPathRoot + "\\fop";
var sPathJava  = window.top.BTMDB.RootURL  + "\\jre\\jre1.6.0_03\\bin\\java";
var sPathBuild = sPathFOP  + "\\build";
var sPathLib   = sPathFOP  + "\\lib";

// transform file to PDF
var arg = "\"" + sPathJava + "\" ";
arg    += "-cp \"";
arg    += sPathBuild + "\\fop.jar;";
arg    += sPathLib + "\\xml-apis.jar;";
arg    += sPathLib + "\\xercesImpl.jar;";
arg    += sPathLib + "\\xalan.jar;";
arg    += sPathLib + "\\serializer.jar;";
arg    += sPathLib + "\\batik-all.jar;";
arg    += sPathLib + "\\xmlgraphics-commons.jar;";
arg    += sPathLib + "\\avalon-framework.jar;";
arg    += sPathLib + "\\commons-io.jar;";
arg    += sPathLib + "\\commons-logging.jar;\" ";
arg    += "org.apache.fop.cli.Main ";
arg    += "-xml " + sXmlUrl + " ";
arg    += "-xsl " + sXslUrl + " ";
arg    += "-pdf " + sPdfUrl + " ";
arg    += "-nocopy " + " ";
arg    += "-noedit " + " ";
arg    += "-noannotations";

// run (<application & params>, <[0|1] - process in background|foreground>, 
// <[true|false] wait till finished>
var nEcode = aShell.Run (arg, 0, true);

if (nEcode != 0)
{
  alert ("[ErrPDF-01]\nError while transforming. Send file:\n-> " + sXmlUrl 
+ "")
  window.top.TransferToCCA9 (sXmlUrl);
  return;
}

// show result
if (bShowPdf)
{
  var arg = "cmd /c \"" + sPdfUrl;

  // run (<application & params>, <[0|1] - process in background|foreground>, 
  // <[true|false] wait till finished>
  aShell.Run (arg, 0, false);
}

(In reply to comment #8)
<snip/>
> Is it possible that on a slow machine, the pdf file is not completely written 
> (buffer not completely emptied) while the FOP process signals the system it is 
> ready and now acrobat opens a file where e.g. some crucial font information at 
> the end of the file is not available, yet? When you open the file a second time 
> the file is complete and therefore one can print it...
<snip/> 

That would mean that the aShell.Run command returns before the Java process has
completely finished. At any rate, the output file is properly finalized and
closed by FOP (I've checked). So, no, I can't imagine that there are still any
open buffers or something like that around (except in a faulty operating system
which would be a catastrophe and not affect only one program). Furthermore,
Acrobat usually notifies me if I want to open a PDF that is incomplete/corrupt.
I still believe in a bug in Acrobat but I could be wrong. Have you tried a
different PDF viewer? I know using Acrobat could be company policy but just in
order to narrow down the problem such an experiment could be worthwhile.

resolved invalid due to lack of information (FO input file, PDF output file, etc)

batch transition resolved+invalid to closed+invalid