| 1 |
Il 08/12/2014 00:17, Martin Vaeth ha scritto: |
| 2 |
> Michał Górny <mgorny@g.o> wrote: |
| 3 |
>> Have you tried mcpdf? |
| 4 |
> I heard about it now for the first time. |
| 5 |
> |
| 6 |
> If I understand correctly, it uses the same library |
| 7 |
> as pdfTK, only a somewhat later version |
| 8 |
> (e.g. with improved unicode handling). |
| 9 |
> |
| 10 |
> The main difference seems to be that it does not insist |
| 11 |
> on gcj but apparently should work with any java: I had |
| 12 |
> suspected that it is the library which depends on some |
| 13 |
> gcj internals and not just the front-end which consists |
| 14 |
> just of a few lines, anyway. |
| 15 |
> |
| 16 |
> So, indeed, this looks like it should be a drop-in |
| 17 |
> replacement, though I did not check whether the |
| 18 |
> license of the updated library changed. |
| 19 |
> |
| 20 |
> Anyway, it would be nice to have it in the tree. ;) |
| 21 |
> |
| 22 |
>> but testing with your tricky PDFs |
| 23 |
> I do not remember anymore. I just remember that |
| 24 |
> several times, when some deadline approached, |
| 25 |
> I had to resort to pdftk at my institute's Debian |
| 26 |
> (in the lack of a gcj at home), even for simple tasks |
| 27 |
> as merging pdftex output with some scanned PDF pages: |
| 28 |
> neither pdfjam nor poppler did it satisfactory, |
| 29 |
> though I do not remember the reasons. |
| 30 |
> |
| 31 |
A simple concatenation does not work for me: |
| 32 |
|
| 33 |
$ alias pdftk='java -jar /srv/git/M/mcpdf-0.2.1-jar-with-dependencies.jar' |
| 34 |
$ pdftk \ |
| 35 |
> 4265498/0010-visura_alvise.pdf 4265498/report_sister_AT00.pdf |
| 36 |
4265499/0010-visura_alvise.pdf \ |
| 37 |
> cat output OUT.pdf |
| 38 |
java.lang.RuntimeException: Unknown operation: |
| 39 |
4265498/report_sister_AT00.pdf |
| 40 |
See README for more information. |
| 41 |
|
| 42 |
also having it in tree would be better, and a pair of warnings: |
| 43 |
|
| 44 |
- The project only has 20 commit, last one 8 months ago |
| 45 |
https://github.com/m-click/mcpdf.git |
| 46 |
- in the readme there is this "Note that not all PDFtk operations are |
| 47 |
implemented at the moment." |
| 48 |
|
| 49 |
hardly a drop in I would trust to replace pdftk which only had problems |
| 50 |
once (at compile time) because of a gcc upgrade. |
| 51 |
|
| 52 |
but |
| 53 |
find /g/portage/ -name '*.ebuild' -exec egrep 'sys-devel/gcc.*gcj' {} + |
| 54 |
show that really only pdftk, dev-java/ecj-gcj and dev-java/gcj-jdk |
| 55 |
depend on gcc with gcj enabled. |
| 56 |
maybe too few to maintain a broken gcc extension, probably also "go" |
| 57 |
should go |
| 58 |
|
| 59 |
regards, |
| 60 |
Francesco Riosa |
Archives