Re: Google Summer of Code: Bring out your projects

Hi everyone,
>> If I understand correctly, you can register your proposed projects in
>> JIRA, see the above web page.
Oops, I missed that sentence; today, while revisiting this thread I
noticed that, according to the timeline [1], the proposals will need
to be postponed for next year. The deadline was pretty short,
though (apparently only a couple of days for JIRA creation + final
proposal compilation).
Somehow related, in the guide to being a mentor, it's stated in the
procedure that one should "Add an issue to JIRA (if your project
doesn't use JIRA contact dev <at> community.apache.org)" [2]. Could anyone
help understanding what is that exactly? I've crawled through the
available JIRA projects and saw none related with XML Graphics (Batik,
FOP, XML Graphics Commons)... (Also, if this is a lengthy process I'd
hint towards maybe triggering the process now so next year we won't
have this extra overhead.)
Regards,
Helder
[1] http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/timeline
[2] http://community.apache.org/guide-to-being-a-mentor.html#guidetobeingamentor-Summary

Re: Google Summer of Code: Bring out your projects

Simon Pepping <spepping <at> leverkruid.eu>
2010-04-06 07:01:48 GMT

On Mon, Apr 05, 2010 at 04:34:45PM +0100, Helder Magalhães wrote:
> Hi everyone,
>
> Somehow related, in the guide to being a mentor, it's stated in the
> procedure that one should "Add an issue to JIRA (if your project
> doesn't use JIRA contact dev <at> community.apache.org)" [2]. Could anyone
> help understanding what is that exactly? I've crawled through the
> available JIRA projects and saw none related with XML Graphics (Batik,
> FOP, XML Graphics Commons)... (Also, if this is a lengthy process I'd
> hint towards maybe triggering the process now so next year we won't
> have this extra overhead.)
JIRA is the ASF's bug tracking system, used by many projects instead
of Bugzilla which we use. You can find it at
https://issues.apache.org/jira/browse/INFRA. See also the Development
Infrastructure page http://www.apache.org/dev/, the section on issue
tracking, http://www.apache.org/dev/#issues.
dev <at> community.apache.org is the public mailing list of the ASF's
Community Development Committee (see
http://community.apache.org/index.html), who lead the ASF's GSoC
efforts. See the archives at
http://mail-archives.apache.org/mod_mbox/community-dev/. Registering
your project ideas should not take a long time.
Regards, Simon
--
--
Simon Pepping
home page: http://www.leverkruid.eu

Re: Google Summer of Code: Bring out your projects

Hi everyone,
>> Could anyone
>> help understanding what is that exactly? I've crawled through the
>> available JIRA projects and saw none related with XML Graphics (Batik,
>> FOP, XML Graphics Commons)... (Also, if this is a lengthy process I'd
>> hint towards maybe triggering the process now so next year we won't
>> have this extra overhead.)
>
> JIRA is the ASF's bug tracking system, used by many projects instead
> of Bugzilla which we use.
[...]
Humm, I guess my question wasn't properly made (I had an idea of JIRA
as a bug tracker and it's use within ASF); I meant to ask what were
the implications of using JIRA when the project is using Bugzilla.
Sorry for the noise!
> See the archives at
> http://mail-archives.apache.org/mod_mbox/community-dev/. Registering
> your project ideas should not take a long time.
OK, a little crawling showed that it is straightforward [1], with no
implications at all: the procedure for projects using Bugzilla is
simply using the "Community Development" project on JIRA, making sure
the title has prefix containing the project name ("PROJECT_NAME:").
More details available [1].
> Regards, Simon

DO NOT REPLY [Bug 49052] New: -dpi setting does not work well.

<bugzilla <at> apache.org>
2010-04-06 10:29:26 GMT

https://issues.apache.org/bugzilla/show_bug.cgi?id=49052
Summary: -dpi setting does not work well.
Product: Batik
Version: 1.7
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: SVG Rasterizer
AssignedTo: batik-dev <at> xmlgraphics.apache.org
ReportedBy: peterhull90 <at> gmail.com
Created an attachment (id=25234)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25234)
zip containing 'good' and 'bad' svg files and pngs at 100 and 200dpi
If an SVG file contains a width/height in 'real' units but no viewBox attribute
on the svg tag, and the image contains graphics in pixel units, the rasterizer
works ok if the -dpi command line parameter is 100 but not otherwise when
converting to raster formats. If, for example, the dpi is set to 200 the image
is physically twice the size but the graphic is not, it stays in the top left
hand corner.
Rasterizer must be using an implicit DPI of 100 to draw the graphic so it
probably should generate an implicit viewBox based on the width/height. As far
as I can see the viewBox is not required by SVG and the observed behaviour is
not in the SVG spec, apologies if I have missed it.

DO NOT REPLY [Bug 49052] -dpi setting does not work well.

<bugzilla <at> apache.org>
2010-04-06 10:49:11 GMT

https://issues.apache.org/bugzilla/show_bug.cgi?id=49052
Thomas Deweese <deweese <at> apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Thomas Deweese <deweese <at> apache.org> 2010-04-06 10:49:10 UTC ---
It sounds like the '-dpi' switch is working fine.
The 'dpi' switch changes the mapping from realworld units to userspace
units. Not the other way around. So without the viewBox attribute you are
changing the effective width and height of the SVG in userspace but
your document uses the same portion of the userspace.
--
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 49061] ClassCastException using org.apache.batik.swing.JSVGCanvas.setDocument

<bugzilla <at> apache.org>
2010-04-07 10:02:17 GMT

https://issues.apache.org/bugzilla/show_bug.cgi?id=49061
Thomas Deweese <deweese <at> apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Thomas Deweese <deweese <at> apache.org> 2010-04-07 10:02:16 UTC ---
The DOM you are building is broken.
If you have a question on using Batik, ask them on the Batik-Users list, do not
post bugs (strike 2).
--
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

I tracked this down to SVGLinearGradientElementBridge.buildGradient:128 where the code returns a null Paint because the line's width is 0px. However, shouldn't the code be checking the stroke-width instead? (20px)

This example is based on the following W3C SVG spec test file which renders correctly in Firefox and Chrome.