Okay, last night I merged pretty much everything I wanted to get in for this release. Does anyone else have stuff they want to slot in for 0.44.1? Now's your last chance.
Once the last of that stuff is in, we'll notify the translators mailing list so they can get any translation issues sorted. Meanwhile, we test, validate some of the packaging changes which were comitted, and once they're finished we can tag and release.
Do you think we should do any 0.44.1 prereleases to get wider testing?
-mental
MenTaLguY wrote:
Does anyone else have stuff they want to slot in for 0.44.1? Now's your last chance.
What about some of the Ps and Pdf fixes that have been applied to trunk? http://sourceforge.net/tracker/index.php?func=detail&aid=1514638&gro...
I would suggest all except the Ps transparency/mask and the Pdf group opacity. Or, as a minimum, include the patch to avoid miterlimits<1 and re-enable the old ps->pdf exporter for those who wish to have images and text objects in their pdf's.
Let me know if you wish me to prepare a patch for the stable branch (and what fixes to include) and I will try look at it tomorrow.
On Tue, 2006-08-01 at 22:43 +0200, Ulf Erikson wrote:
MenTaLguY wrote:
Does anyone else have stuff they want to slot in for 0.44.1? Now's your last chance.
What about some of the Ps and Pdf fixes that have been applied to trunk? http://sourceforge.net/tracker/index.php?func=detail&aid=1514638&gro...
I would suggest all except the Ps transparency/mask and the Pdf group opacity. Or, as a minimum, include the patch to avoid miterlimits<1 and re-enable the old ps->pdf exporter for those who wish to have images and text objects in their pdf's.
Let me know if you wish me to prepare a patch for the stable branch (and what fixes to include) and I will try look at it tomorrow.
Yes, let's get those in. Would it be easy to get each fix in a separate patch, so we can look at the impact of each one individually?
I wouldn't mind re-enabling the old PDF export either, but we should figure out how we should differentiate between it and the new exporter name-wise.
-mental
MenTaLguY wrote:
On Tue, 2006-08-01 at 22:43 +0200, Ulf Erikson wrote:
MenTaLguY wrote:
Does anyone else have stuff they want to slot in for 0.44.1? Now's your last chance.
What about some of the Ps and Pdf fixes that have been applied to trunk?
Yes, let's get those in. Would it be easy to get each fix in a separate patch, so we can look at the impact of each one individually?
I have opened Patch #1533405 ([STABLE] Ps and Pdf fixes) and included each fix separately as well as a single all-in-one patch.
I wouldn't mind re-enabling the old PDF export either, but we should figure out how we should differentiate between it and the new exporter name-wise.
Could something as "PDF via Postscript" do? I recall an earlier thought that the new exporter ought to be named "PDF 1.4" (or was that about mentioning it in the release notes?), but I guess that means even less to regular users.. "PDF with text and images" vs. "PDF with transparency" might be the clearest when it comes to possibilities (and limitations?)
On Wed, 2006-08-02 at 21:36 +0200, Ulf Erikson wrote:
Could something as "PDF via Postscript" do? I recall an earlier thought that the new exporter ought to be named "PDF 1.4" (or was that about mentioning it in the release notes?), but I guess that means even less to regular users.. "PDF with text and images" vs. "PDF with transparency" might be the clearest when it comes to possibilities (and limitations?)
That seems reasonable. I've comitted everything you've given me; please check out a copy from branch/RELEASE_0_44_BRANCH and make sure everything is the way you expect.
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...
Also, are there any transparency-related fixes available for the PDF exporter? I recall transparency being relatively limited in key areas.
-mental
If it's not too late, here's one more fix for 0.44.1:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/svg/svg-color....
Without it, Inkscape can't read "rgb(xx%,xx%xx%)" colors - bug was introduced by pjrm in revision 11201, 4 months ago.
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.
On 8/3/06, Ulf Erikson <ulferikson@...400...> wrote:
Yes, I have a transparency related fix as well, but it is a bit more involved and bulia had some issues with it.
Yes, sorry I dropped the ball here. We agreed to do a function which gives the visible opacity of an object, right? Please keep reminding me so I don't forget about it again :)
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.
Elliptic gradients with transparency did work for me on fill.
bulia byak wrote:
On 8/3/06, Ulf Erikson <ulferikson@...400...> wrote:
Yes, I have a transparency related fix as well, but it is a bit more involved and bulia had some issues with it.
Yes, sorry I dropped the ball here. We agreed to do a function which gives the visible opacity of an object, right? Please keep reminding me so I don't forget about it again :)
Right. Will do so.
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.
Elliptic gradients with transparency did work for me on fill.
True. I must have misread the release notes where it says "no eccentric elliptic gradients". As you say, elliptic gradients do work, but also eccentric gradients do work. The issue is that they only work as long as the cross is inside the circle, and.. in the libnr code I found the math to ensure this.
Could you please try this patch? Between "double r = rg->r.computed;" and "if (pbox && SP_GRADIENT(rg)->units == ..." and the following lines (once in ps.cpp and twice in pdf.cpp). Seems to do it for me: --- NR::Coord const df = hypot(f[NR::X] - c[NR::X], f[NR::Y] - c[NR::Y]); if (df >= r) { f[NR::X] = c[NR::X] + (f[NR::X] - c[NR::X] ) * r / (float) df; f[NR::Y] = c[NR::Y] + (f[NR::Y] - c[NR::Y] ) * r / (float) df; } ---
Maybe we can make a list of features that don't work and discuss possible solutions? Most of it will be equally interesting for the cairo based exporter. Bug 1170322 (Clippath does not work in PS export), for instance. I have no idea how clips and masks are exposed to extensions.
On Thu, Aug 03, 2006 at 10:21:33AM +0200, Ulf Erikson wrote:
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)
I use the commandline export capability quite often, and actually find the --export-pdf/ps/eps/etc. to be not that big of a deal. In fact, I'd sort of like even finer grained control - being able to select exactly *which* pdf exporter to use. As mentioned, there are multiple ways to get pdf's, and depending on the file, one converter may work better than another.
So... maybe --export-with=CONVERTER would be the proper approach, and then we could have 'pdf-cairo', 'pdf-ps2pdf', 'pdf-scribus', ... as options, with plain 'pdf' pointing to whichever converter the inkscape team feels to be the ideal default pdf converter.
I imagine this would also enable more dynamic addition of conversion filetypes. Presently, even though you can easily add a new inkscape extension via the .inx files, you can't use it from inkscape's commandline interface without adding a new cmdline option to main.cpp.
Bryce
MenTaLguY <mental@...3...> writes:
Okay, last night I merged pretty much everything I wanted to get in for this release.
FWIW, after our discussion on IRC and your commit 12837, Inkscape built fine and also seems to run (I just have the datarootdir problem with autoconf 2.60 that I didn't patch away yet (https://sourceforge.net/tracker/index.php?func=detail&aid=1521963&gr...).
Cheers, Colin
participants (5)
-
Bryce Harrington -
bulia byak -
Colin Marquardt -
MenTaLguY -
Ulf Erikson