A Divendres, 20 d'agost de 2010, Adrian Johnson va escriure: > On 19/08/10 18:30, Stefan Thomas wrote: > > Hey again, > > > >> Following modification can drop the page number suffix in > >> output filename when "split" flag is disabled. Stefan, could > >> you review? > > > > Makes sense and works great! Thanks! > > > > A Dissabte, 31 de juliol de 2010, Adrian Johnson va escriure: > >> I've just done some testing with the patches and found a problem with > >> the generated output file name. > >> > >> My original patch would, if no output file name is specified, use the > >> input filename to generate the output name like what pdftops does. eg > >> > >> "pdftocairo -ps foo.pdf" will create foo.ps > >> "pdftocairo -png foo.pdf" will create foo-001.png, foo-002.png, ... > >> > >> the updated patches are doing: > >> > >> "pdftocairo -ps foo.pdf" will create cairoout-001.ps > >> "pdftocairo -png foo.pdf" will create cairoout-001.png, > >> cairoout-002.png, ... > >> > >> which is not very user friendly. > > > > The reason for this change was that the previous way of determining > > outRoot gave unwanted results when you gave it a remote PDF like: > > > > "pdftocairo -ps http://m.je/test.pdf"; will try to create > > http://m.je/test.ps > > > > Didn't like URLs without a real filename either: > > > > "pdftocairo -ps http://example.com/get?format=pdf&asset=3948"; will try > > to create http://example.ps > > > > Another problem was that it would create output files in the directory > > where the PDF file resides rather than in the current working directory > > which is unusual for *NIX command line tools. > > > > "pdftocairo -ps /media/cdrom0/pdfs/mytest.pdf" -> write error > > > > The current version (with mpsuzuki's fix) will create "cairoout.ps" in > > the current working directory in all of those cases. Plus you can always > > provide a second parameter if you'd like a different name. I'm liking > > the predictability of it. > > > > As I see it we have three options: > > > > 1. Current way: Always use "cairoout", unless otherwise specified by the > > user. > > > > 2. Adrian's way: Create outRoot from input filename. Perhaps with some > > improvements like cutting off everything before the last slash (if it > > exists), then everything after the first question mark (if it exists), > > then everything after the last dot (if it exists). If the result is > > empty or otherwise not a valid filename, use "cairoout". > > > > 3. pdftoppm's way: Output to STDOUT unless a second parameter with an > > output filename is provided. > > > > I'd be happy with any of these. I'm liking about number one that I know > > there aren't any bugs in it. With number 2 I feel like there is always > > going to be a URL or filename that breaks it/acts weird. I'm liking > > about number three that it's consistent with pdftoppm. > > > > Thoughts? > > My preference is to maintain consistency with the other poppler utils. > > pdftops, pdftotext, and pdftohtml all use the source file with the > extension changed. I prefer pdftocairo to work the same way.
Totally agreed here. Stefan, how difficult would be to make pdftocairo behave like these programs? Albert P.S: Sorry for the very very very very late reply > > pdftoppm is the exception in writing to stdout if no output name is > specified. This only makes sense for the ppm format which allows > multiple images concatenated together. Writing multiple images to > stdout does not work with the png or jpeg formats. > > Currently none of the other poppler utils (except pdftoppm which writes > to stdout) handle URLs with no output file specified. Whatever solution > is chosen for providing default filenames for URLs should be > consistently implemented across all the poppler utils. I would suggest > implementing behavior similar to wget. ie strip off everything up to > the last slash and escape any characters not supported by the > filesystem. Since the other poppler utils do not work with URLs with no > output file specified, I don't think finding a solution for this case > should block the committing of pdftocairo. > > > I'll make a final patch once we've decided the filename issue. > > > > Cheers, > > > > Stefan > > _______________________________________________ > > poppler mailing list > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/poppler > > _______________________________________________ > poppler mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/poppler _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
