Bug 71038

Created attachment 88344 [details]
Comparison of the results

Created attachment 88345 [details]
The pdf file for testing

I used Poppler 0.24.3 on a 64bit Mac to run

   pdftops -level3 testFile.pdf testFile.ps

which outputs a 25 MByte file (from a 514 kByte source PDF) with lots of complaints (virtually hundreds of lines) about:

  [....]
  Syntax Warning: SOT marker inconsistency in tile 0: tile-part index greater (5) than number of tile-parts (5)<0a>
  Syntax Warning: SOT marker inconsistency in tile 1: tile-part index greater (5) than number of tile-parts (5)<0a>
  Syntax Warning: SOT marker inconsistency in tile 2: tile-part index greater (5) than number of tile-parts (5)<0a>
  Syntax Warning: SOT marker inconsistency in tile 3: tile-part index greater (5) than number of tile-parts (5)<0a>
  Syntax Warning: SOT marker inconsistency in tile 0: tile-part index greater (5) than number of tile-parts (5)<0a>
  Syntax Warning: SOT marker inconsistency in tile 1: tile-part index greater (5) than number of tile-parts (5)<0a>
  Syntax Warning: SOT marker inconsistency in tile 2: tile-part index greater (5) than number of tile-parts (5)<0a>
  Syntax Warning: SOT marker inconsistency in tile 3: tile-part index greater (5) than number of tile-parts (5)<0a>
  Syntax Warning: SOT marker inconsistency in tile 0: tile-part index greater (5) than number of tile-parts (5)<0a>
  Syntax Warning: SOT marker inconsistency in tile 1: tile-part index greater (5) than number of tile-parts (5)<0a>
  Syntax Warning: SOT marker inconsistency in tile 2: tile-part index greater (5) than number of tile-parts (5)<0a>
  Syntax Warning: SOT marker inconsistency in tile 3: tile-part index greater (5) than number of tile-parts (5)<0a>
  [....]

However, using gv and Ghostscript, the resulting PS file displays correctly.

Thanks for you reply, Kurt.

I think that the size issue is due to de background image of the original pdf. I have created a new pdf with the text only to avoid it.
If you could try with this new pdf (testFile2.pdf) and tell us if it also throws complaints. (I see no complaints at all, not with testFile.pdf, neither with testFile2.pdf)
I also attach the resulting incorrect ps file.

If in your machine the result is correct may be Centos has something to do... can anyone try in a Centos 64bit environment? Thanks.

Created attachment 88889 [details]
Modified pdf file for testing

Created attachment 88890 [details]
ps result with missing letters

That is weird, it works perfectly fine here with poppler 0.24.3 on a 64 bit machine.

Can you test that the two .ps files produced are indeed different? i.e. use the diff command on them.

Created attachment 90706 [details]
ps result ok in 32bit centos

Hi Albert,I have added an attachment with the ps we get in centos 32bits. This one has no missing letters, and as you can see, the size is different and the diff also.

The test you ran was in a Centos 64bit? Thanks.

Hmmm, the diff says

-%%LanguageLevel: 2
+%%LanguageLevel: 3

at the very top, are you sure you're using exactly the same options to generate both .ps files?

Created attachment 90827 [details]
ps result ok in 32bit centos - ps level 3

Yes, I forgot the "-level3" options in my last attachment, I have added I new one for better comparison. But the problem remains the same (refer to Comment 9)

does running pdftops under valgrind give you any warning?

(In reply to comment #13)
> does running pdftops under valgrind give you any warning?

Hi again,

here is valgrind output for our CentOS 64bits machine.
(trimmed out unimportant lines)

valgrind pdftops testFile2.pdf:
==16029==
==16029== HEAP SUMMARY:
==16029==     in use at exit: 68,754 bytes in 868 blocks
==16029==   total heap usage: 27,187 allocs, 26,319 frees, 248,213,759 bytes allocated
==16029==
==16029== LEAK SUMMARY:
==16029==    definitely lost: 0 bytes in 0 blocks
==16029==    indirectly lost: 0 bytes in 0 blocks
==16029==      possibly lost: 0 bytes in 0 blocks
==16029==    still reachable: 68,754 bytes in 868 blocks
==16029==         suppressed: 0 bytes in 0 blocks
==16029== Rerun with --leak-check=full to see details of leaked memory
==16029==
==16029== For counts of detected and suppressed errors, rerun with: -v
==16029== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

valgrind --tool=helgrind
==17953== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

valgrind --tool=drd
==22923== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Trying to get an unified testing enviroment i have also tried vagrant+virtual box running this image (CentOS 6.5 64bit): 

https://github.com/2creatives/vagrant-centos/releases/download/v0.1.0/centos64-x86_64-20131030.box

minimal setup for vagrant just name of the box+url all the rest default options.

I ran it in Centos 32bits as host OS. (in this machine pdftops outputs correct ps files.)

Inside Centos 6.5 VM just:
yum install poppler-utils (v 0.12.4 in repo)
pdftops /pathTo/testFile2.pdf /pathTo/testFile2.ps -> missing letters in this testFile2.ps file again. (as viewed with evince)

This way you can test in the "same" environment.

Inside VM valgrind outputs the same:

[vagrant@vagrant-centos65 ~]$ valgrind --leak-check=yes pdftops /vagrant/Descargas/testFile2.pdf
==7699== Memcheck, a memory error detector
==7699== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==7699== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==7699== Command: pdftops /vagrant/Descargas/testFile2.pdf
==7699==
==7699==
==7699== HEAP SUMMARY:
==7699==     in use at exit: 55,370 bytes in 709 blocks
==7699==   total heap usage: 26,720 allocs, 26,011 frees, 247,867,541 bytes allocated
==7699==
==7699== LEAK SUMMARY:
==7699==    definitely lost: 0 bytes in 0 blocks
==7699==    indirectly lost: 0 bytes in 0 blocks
==7699==      possibly lost: 0 bytes in 0 blocks
==7699==    still reachable: 55,370 bytes in 709 blocks
==7699==         suppressed: 0 bytes in 0 blocks
==7699== Reachable blocks (those to which a pointer was found) are not shown.
==7699== To see them, rerun with: --leak-check=full --show-reachable=yes
==7699==
==7699== For counts of detected and suppressed errors, rerun with: -v
==7699== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

[vagrant@vagrant-centos65 ~]$ valgrind --tool=drd pdftops /vagrant/Descargas/testFile2.pdf
==1463== drd, a thread error detector
==1463== Copyright (C) 2006-2012, and GNU GPL'd, by Bart Van Assche.
==1463== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==1463== Command: pdftops /vagrant/Descargas/testFile2.pdf
==1463==
==1463==
==1463== For counts of detected and suppressed errors, rerun with: -v
==1463== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

etc...

Valgrind info was provided.

Created attachment 111947 [details]
PDF, all chars visible

Created attachment 111948 [details]
PS, last char from PDF is missing

I've encountered a similar issue (small testcase attached). The page uses a Chinese font, but all characters except for one are working.

In Centos 7 (64 bits), tested with pdftops 0.30.0 and 0.32.0, the resulting ps displays correcly for the original testFile (attachment 88345 [details]) (But with the same warnings as in comment #3)