MenTaLguY wrote:
Incidentally, it's the newer transparency-enabled PDF export used with the commandline export if I understand correctly? We should note that in the release notes...
Hmm.. It looks like the first extension found with mime-type "application/pdf" will be used. In stable that's only the native exporter, but for trunk the cairo-based pdf exporter uses the same mime-type. I don't know how to tell which exporter will be used then.
What about, instead of all the --export-pdf/ps/eps/png, a single --export-file=FILENAME.EXT and pick an internal or external extension based on .EXT if it is unique or list the Id's of available extensions for .EXT otherwise. Also, add an --export-through=EXTENSION-ID for the case that .EXT is not unique or the user wishes to use a filename without the regular .EXT. Does this sound reasonable as an RFE for trunk or plain nonsense? (I rarely use the commandline interface of Inkscape myself)
Also, are there any transparency-related fixes available for the PDF exporter? I recall transparency being relatively limited in key areas.
Yes, I have a transparency related fix as well, but it is a bit more involved and bulia had some issues with it.. The bug is #1511590 (PDF export omits opacity inherited from parent). The hinted work-around is to ungroup everything before exporting. If you have a concrete example you can compare the results of trunk (where the fix is included) and stable.
For the rest, transparency use is as limited as the regular colours and many of the limitations are shared with the postscript exporter that I based the pdf exporter on (i don't know enough about inkscape or pdf internals to handle it). For instance, there are no gradients for strokes, and there are no elliptic or excentric gradients for fills.