You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Andres Toussaint <an...@onemileup.com> on 2005/07/15 00:22:17 UTC

Normalize path d attribute

Is there a way to apply the result of a: 
SVGOMPathElement.getNormalizedPathSegList(); to the "d" attribute of 
the original path?

Basically, I want to convert all relative coordinates to absolute ones, 
in all my path elements, so that when i save-export the SVG Document, 
the paths have absolute (or normalized) "d" attributes only.

I can see a way to do it, using a SVGOMPathSegList parsing routine, but 
was wondering if there was already something out there to do the job.

Thanks,

Andres.


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Re: Normalize path d attribute

Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Andres,

andres@onemileup.com wrote:

>>>SVGOMPathElement.getNormalizedPathSegList() is NOT IMPLEMENTED!
> 
> I have filed a bugzilla for this lack of implementation,
> http://issues.apache.org/bugzilla/show_bug.cgi?id=35773

    Thanks.

> Also, I am interested in offering at least some partial implementation of
> this problem. I definitely would like some guidance as to the complexities
> involved in the live (Animated) attributes.

    This is great.  However for us to use it we would likely need to
have a Contributors License Agreement (CLA) on file:
	http://www.apache.org/licenses/#clas

> In the meanwhile I have created a base implementation of
> getNormalizedPathSegList(), by extending the following classes:
> -SVGOMAnimatedNormPathData extends SVGOMAnimatedPathData
> -AbstractSVGNormPathSegList extends AbstractSVGPathSegList
> 
> My implementation is made follwing how the method getPathSegList() is
> implemented. But I am not sure I am approaching the AnimatedPathData
> constraints in a proper manner. 

    The basic thing is to implement the attrAdded/Modified/Removed
methods to invalidate the current path segments.  Also you
need to provide the getValueAsString and setAttributeValue.

> I am aware that this implementation would
> be better off incorporating it directly into the classes mentioned above
> (instead of extending them). I hope to have time this week to propose a
> basic implementation, specifically of
> SVGOMPathElement.getNormalizedPathSegList(). 

    Yah, I would be tempted to have an extra bit that indicates if the
segment should be normalized before returning it.  One thing that
isn't clear to me is what the proper behavior is when the list is
modified (are you expected to keep the same base type or can you
replace the previous seg type with the abs segment type).

> I still need to figure out how to Normalize a arc segment, all 
> others I have succesfully Normalized.

    The Arc is simple you simply need to make the destination point
an absolute point rather than a relative one.  There is no way to
normalize the radii or the arc flags (or they are already normalized).

> Also, I imagine this thread should be moved to the devel list, right?

    Yes, and done.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org


Re: Normalize path d attribute

Posted by an...@onemileup.com.
Hi Thomas:

>> SVGOMPathElement.getNormalizedPathSegList() is NOT IMPLEMENTED!
>
>     I am not currently doing any work to implement it.  If you have
> questions on how to implement it I could try and help.  It is
> probably worth filling a bugzilla bug report so it doesn't get
> forgotten even if work doesn't start immediately.
>

I have filed a bugzilla for this lack of implementation,
http://issues.apache.org/bugzilla/show_bug.cgi?id=35773

Also, I am interested in offering at least some partial implementation of
this problem. I definitely would like some guidance as to the complexities
involved in the live (Animated) attributes.

In the meanwhile I have created a base implementation of
getNormalizedPathSegList(), by extending the following classes:
-SVGOMAnimatedNormPathData extends SVGOMAnimatedPathData
-AbstractSVGNormPathSegList extends AbstractSVGPathSegList

My implementation is made follwing how the method getPathSegList() is
implemented. But I am not sure I am approaching the AnimatedPathData
constraints in a proper manner. I am aware that this implementation would
be better off incorporating it directly into the classes mentioned above
(instead of extending them). I hope to have time this week to propose a
basic implementation, specifically of
SVGOMPathElement.getNormalizedPathSegList(). I still need to figure out
how to Normalize a arc segment, all others I have succesfully Normalized.

Also, I imagine this thread should be moved to the devel list, right?


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Re: Normalize path d attribute

Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Andres,

Andres Toussaint wrote:
> SVGOMPathElement.getNormalizedPathSegList() is NOT IMPLEMENTED!
> 
> Throws a RuntimeException ( "TODO : getNormalizedPathSegList() !!)
> 
> Is there any work being done at all in this? Is there somebody I can 
> talk about getting it implemented?

    I am not currently doing any work to implement it.  If you have
questions on how to implement it I could try and help.  It is
probably worth filling a bugzilla bug report so it doesn't get
forgotten even if work doesn't start immediately.

> 
> Andres.
> 
> On Jul 15, 2005, at 6:10 AM, Thomas DeWeese wrote:
> 
>> Andres Toussaint wrote:
>>
>>> Is there a way to apply the result of a: 
>>> SVGOMPathElement.getNormalizedPathSegList(); to the "d" attribute of 
>>> the original path?
>>
>>
>>    Not real directly, but you can build a string that should be the
>> 'd' attribute as you walk the path segment list and then just use
>> setAttribute to replace the original when you are done.
>>
>>> Basically, I want to convert all relative coordinates to absolute 
>>> ones, in all my path elements, so that when i save-export the SVG 
>>> Document, the paths have absolute (or normalized) "d" attributes only.
>>> I can see a way to do it, using a SVGOMPathSegList parsing routine, 
>>> but was wondering if there was already something out there to do the 
>>> job.
>>
>>
>>    No, this is one of those 'tool' things that would be nice to
>> have in the 'contrib' section of Batik (relative<->absolute,
>> remove transforms, add transforms (calc minX,Y add a translate for
>> that and then rewrite data to account for that), etc...).
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Re: Normalize path d attribute

Posted by Andres Toussaint <an...@onemileup.com>.
SVGOMPathElement.getNormalizedPathSegList() is NOT IMPLEMENTED!

Throws a RuntimeException ( "TODO : getNormalizedPathSegList() !!)

Is there any work being done at all in this? Is there somebody I can 
talk about getting it implemented?

Andres.

On Jul 15, 2005, at 6:10 AM, Thomas DeWeese wrote:

> Andres Toussaint wrote:
>> Is there a way to apply the result of a: 
>> SVGOMPathElement.getNormalizedPathSegList(); to the "d" attribute of 
>> the original path?
>
>    Not real directly, but you can build a string that should be the
> 'd' attribute as you walk the path segment list and then just use
> setAttribute to replace the original when you are done.
>
>> Basically, I want to convert all relative coordinates to absolute 
>> ones, in all my path elements, so that when i save-export the SVG 
>> Document, the paths have absolute (or normalized) "d" attributes 
>> only.
>> I can see a way to do it, using a SVGOMPathSegList parsing routine, 
>> but was wondering if there was already something out there to do the 
>> job.
>
>    No, this is one of those 'tool' things that would be nice to
> have in the 'contrib' section of Batik (relative<->absolute,
> remove transforms, add transforms (calc minX,Y add a translate for
> that and then rewrite data to account for that), etc...).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: 
> batik-users-help@xmlgraphics.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Re: Normalize path d attribute

Posted by Thomas DeWeese <Th...@Kodak.com>.
Andres Toussaint wrote:
> Is there a way to apply the result of a: 
> SVGOMPathElement.getNormalizedPathSegList(); to the "d" attribute of the 
> original path?

    Not real directly, but you can build a string that should be the
'd' attribute as you walk the path segment list and then just use
setAttribute to replace the original when you are done.

> Basically, I want to convert all relative coordinates to absolute ones, 
> in all my path elements, so that when i save-export the SVG Document, 
> the paths have absolute (or normalized) "d" attributes only.
> 
> I can see a way to do it, using a SVGOMPathSegList parsing routine, but 
> was wondering if there was already something out there to do the job.

    No, this is one of those 'tool' things that would be nice to
have in the 'contrib' section of Batik (relative<->absolute,
remove transforms, add transforms (calc minX,Y add a translate for
that and then rewrite data to account for that), etc...).

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org