SPStyle now uses SPFilterReference
I changed SPStyle to use SPFilterReference for linking up filters, the same as filters use to link up to each other. This simplified SPStyle code (got rid of ad-hoc hreffing, etc) and fixed at least one bug: now filters are no longer lost when you undo an effect from Effects menu. Of course there may be gotchas, so please report to me any crashes and misbehaviors in filters linking (but not rendering - that is Niko's domain now, my changes should not affect that). If all goes smoothly I will similarly switch SPStyle's paintservers (gradients and patterns) which will fix a bunch of other long-standing bugs.
On 6/27/07, bulia byak <buliabyak@...400...> wrote:
If all goes smoothly I will similarly switch SPStyle's paintservers (gradients and patterns) which will fix a bunch of other long-standing bugs.
This is done now, and indeed it closed lots of old bugs. Let me know if you see any misbehavior.
On Tue, 2007-07-03 at 23:11 -0400, bulia byak wrote:
On 6/27/07, bulia byak <buliabyak@...400...> wrote:
If all goes smoothly I will similarly switch SPStyle's paintservers (gradients and patterns) which will fix a bunch of other long-standing bugs.
This is done now, and indeed it closed lots of old bugs.
THANK YOU! :) This has needed doing for such a long time!
-mental
On 7/4/07, MenTaLguY <mental@...3...> wrote:
THANK YOU! :) This has needed doing for such a long time!
Now, the next most popular bug is the clash of IDs on import or cross-document paste. How close are we now to fixing that? What if I just do a hack - adding some random string to all IDs and URIs in the document fragment being inserted to prevent the clash?
On Thu, 2007-07-05 at 01:01 -0400, bulia byak wrote:
Now, the next most popular bug is the clash of IDs on import or cross-document paste. How close are we now to fixing that? What if I just do a hack - adding some random string to all IDs and URIs in the document fragment being inserted to prevent the clash?
Once we have the infrastructure to find all the IDs and references in the pasted fragment, why not check whether each ID is actually clashing, and only change the ones that are?
(At that point we can also check for the unlikely but possible event where the altered ID also clashes, and pick yet another).
-mental
On 7/7/07, MenTaLguY <mental@...3...> wrote:
Once we have the infrastructure to find all the IDs and references in the pasted fragment,
And what remains to be done for this infrastructure to work?
On Sat, 2007-07-07 at 12:28 -0300, bulia byak wrote:
On 7/7/07, MenTaLguY <mental@...3...> wrote:
Once we have the infrastructure to find all the IDs and references in the pasted fragment,
And what remains to be done for this infrastructure to work?
Well, we need to finish implementing it first. But we have some of it already, in the form of SPDocument.
Part of the problem right now is that we do our imports and clipboard in terms of XML::Documents rather than SPDocuments, but XML::Documents don't know about ids or styles or any of that (SPDocuments do). So, switching the SVG import and clipboard code to each use an SPDocument rather than a bare XML::Document would be an important first step.
Then we just need an method somewhere for copying a list of SPObjects (and their descendants and the objects they href) from one SPDocument to another, where the ID fixups can be done, based on looking up IDs in the source and destination SPDocuments.
-mental
participants (2)
-
bulia byak -
MenTaLguY