- Inkscape Devel - Inkscape Mailman

Re : Re : Re : I suck at Perl (or check-markup)
by Nicolas Dufour 24 May '10

24 May '10

Hi, Another check-markup related issue: I've just activated gettext context macro C_() support in po/Makevars in order to include all the status bar messages added in the new node tool, but check-markup now returns an error message for each string, translated or not: ... fr.po: Not in msg format: #: ../src/ui/tool/transform-handle-set.cpp:479 msgctxt "Transform handle tip" msgid "<b>Rotation center:</b> drag to change the origin of transforms" msgstr "" I guess it is related to the new msgctxt line. Bug again, I'm really not a Perl expert... Could you please see if you can fix this issue? Regards, -- Nicolas

1 0

Inkscape 0.48pre0
by Ted Gould 24 May '10

24 May '10

Hey all, I did the release this afternoon, but realized I forgot to write the e-mail! :) None the less, I put together a pre0 release for the upcomming 0.48. Please if packages could look at it and ensure that they can build their package FROM THE TARBALL that would be great for making sure the tarball is useful. Links: https://sourceforge.net/projects/inkscape/files/inkscape/0.48pre0/ MD5: 273b3a032a57e8c557ebfac750d4572e inkscape-0.48pre0.tar.bz2 9cb002bd9ac0c3613ef435fd98551e06 inkscape-0.48pre0.tar.gz 332c4028f582f48e1587c232009a8886 inkscape-0.48pre0.zip --Ted PS - Odd to me is that there's already 72 downloads of the source!

1 0

Re : Re : I suck at Perl (or check-markup)
by Nicolas Dufour 21 May '10

21 May '10

Comments removed from Makefile.am and patch committed in revision 9438. A huge thanks for your patch and explanations! Regards, -- Nicolas

1 0

The path to FREEZE... Woohoo!
by Joshua A. Andler 21 May '10

21 May '10

Hey all, We're roughly 6 weeks behind the proposed schedule... not good, but could be worse. If we stick to it, things could shape up nicely. A quick update... here is the one thing that MUST be done before moving to Freeze... posting of an "alpha" tarball. The following outstanding issues HAVE to be addressed to not be cut (and most unfortunately have not been addressed fully during Frost): *Jon's swatches MUST be initially editable in the F&S dialog. *Jon's new Input Devices dialog needs whatever polish to be good enough (I saw regressions from 0.47 mentioned recently in the tracker). *Jon's "UX" work (specifically UI placement needs to be settled). *Tavmjong's LinuxFund text tool work (we'll take what we can get, great progress has been made!). *Felipe Sanches' color management work. The "not real" (device) cmyk thing MUST be addressed prior to release. I'm not saying to remove, but perhaps disable, it is a part of the SVG spec, but it's not how the CMYK workflow actually works. Now is the time to bring up other possibly blocker bugs. Please speak up... things that can be fixed in point releases and that aren't critical/high priority should not be brought up. Cheers, Josh

4 4

Re : Re : I suck at Perl (or check-markup)
by Nicolas Dufour 21 May '10

21 May '10

>De : Lucas Vieites <lucasvieites@...400...> >Would it work to use the < and > entities in the original strings? The original string is already "<width>x<height>". intltools extract it as "<width>x<height>" to the pot file, which is the correct behavior. The issue is due to the check-markup perl script, which detects "invalid" markups in the translated strings (or markups which are not correctly closed, etc.). And <width> and <height> are not allowed by the script... Regards. -- Nicolas

1 0

I suck at Perl (or check-markup)
by Ted Gould 21 May '10

21 May '10

Hey, So I was trying to make a release but the check-markup script is failing because of the strings "<width>x<height>" which it thinks is a tag. I tried fixing the check-markup script to ignore this, but well, read the subject :) Could someone who knows Perl help out here? Here's the output: perl ../po/check-markup ../po/*.po br.po: parsing error for `<width>x<height>': #. i18n. Description duplicated in a fake value attribute in order to make it translatable #: ../share/extensions/webslicer_create_rect.inx.h:12 msgid "Force Dimension must be set as <width>x<height>" msgstr "Bountañ war ar Vent a rank bezañ arventennet evel <width>x<height>" fr.po: parsing error for `<width>x<height>': #. i18n. Description duplicated in a fake value attribute in order to make it translatable #: ../share/extensions/webslicer_create_rect.inx.h:12 msgid "Force Dimension must be set as <width>x<height>" msgstr "Imposer la dimension doit être défini sous la forme « <width>x<height> »" ja.po: parsing error for `<width>x<height>': #. i18n. Description duplicated in a fake value attribute in order to make it translatable #: ../share/extensions/webslicer_create_rect.inx.h:12 msgid "Force Dimension must be set as <width>x<height>" msgstr "サイズ強制は <幅>x<高さ> のように設定してください。" nl.po: parsing error for `<width>x<height>': #. i18n. Description duplicated in a fake value attribute in order to make it translatable #: ../share/extensions/webslicer_create_rect.inx.h:12 msgid "Force Dimension must be set as <width>x<height>" msgstr "Dimensies forceren moet ingesteld worden als <breedte>x<hoogte>" ru.po: parsing error for `<width>x<height>': #. i18n. Description duplicated in a fake value attribute in order to make it translatable #: ../share/extensions/webslicer_create_rect.inx.h:12 msgid "Force Dimension must be set as <width>x<height>" msgstr "" make[1]: *** [distcheck-hook] Error 1 Thanks, Ted

2 1

Coding style question
by unknown＠example.com 19 May '10

19 May '10

Hi all, Is it good practice to start class member variables with an underscore? The reason I ask is for ambiguity in a function in a class that is derivative of SPObject. class SPObject has member "repr". So now if I subclass from that and add a method to my class like "sp_do_something(XML::Node repr)", there is an ambiguity in the method. Perhaps underscoring the class member variables is better... Ciao, Johan

2 1

Snapping options anomalies? - Selector tool
by Mihaela 18 May '10

18 May '10

What is the policy on snapping nodes to stuff when dragging the whole object (Selector tool) VS snapping only nodes to stuff (Node tool)? There are some things I'm confused about, some of them might be bugs, others might just be my misinterpretation. Enable "Snapping nodes or handles" and try to snap cusp or smooth nodes using Node tool to a guide, everything works as expected, they snap and the tooltip is correct. If I convert a node to Symmetric it snaps to the guide but the tooltip says "Cusp node to guide". If I convert a node to Auto-smooth it snaps to the guide but the tooltip says "Smooth node to guide". Now with the same setting (Snapping nodes or handles) use Selector tool to move the object around and snap it's nodes to the guide. Snapping sharp cusp nodes works and the tooltip is correct. Snapping cusp nodes that were converted from smooth (so their handles are collinear) doesn't work, even if you move a handle just a bit so handles aren't collinear. Symmetric nodes don't snap. Auto-smooth nodes don't snap. When I add the "Snap to smooth nodes" into play then smooth nodes snap to the guide when using Selector tool, but the tooltip says "Cusp node to guide". It's the same with symmetric and auto-smooth nodes - they snap but the tooltip says cusp. No snapping occurs if I use "Snap to cusp nodes" instead of "Snap to smooth nodes" when trying to snap smooth, symmetric or auto-smooth node using Selector (cusp nodes snap correctly even without this option). It's the same when I want to snap to paths or path intersections (Selector tool), I need to have "Snap to smooth nodes" enabled to do it with nodes that aren't obviously cusp. When snapping to path intersection is on, when trying to snap to a cusp node the tooltip says it's snapping to "path intersection" instead of "to cusp node" and it happens with "Snap to cusp nodes" disabled. Unrelated to this but related to gradients snapping - when creating a gradient start stop snaps but the gradient can't be created. You have to click next to the snapping point and not directly on it to make it work. Is this expected? This is all tested on 9425 but some of it behaves the same in 0.47. Mihaela

2 1

Tool Order
by Tavmjong Bah 17 May '10

17 May '10

Hi, I propose to change the tool order to move the spray tool down and the text tool up a bit. The spray tool is quite neat but I can't imagine using it more than the text tool! The specific order would be: Selector Node Tweak Zoom Rectangle Box Circle/Ellipse Star/Polygon Spiral Pencil Pen Calligraphy Text Spray Eraser Bucket Fill Gradient Dropper Connector Tav

4 3

gradient mesh
by sid datta 17 May '10

17 May '10

Hi, Are we still waiting for the SVG standards before we can implement gradient meshes ? I have a ( pretty simple and obvious ) method of rendering gradient meshes that is simpler than blurring multiple beziergons and is quite fast ( 100 ms in Java rendering 500x500px approx ), I was wondering if we start putting a basic gradient mesh in inkscape and we can conform/export to the SVG format when it comes out. I believe we are trying to get a triangle gradient primitive approved from SVG. Do we have any plans of getting a quadrilateral primitive ? It will be more accurate for gradient mesh. This paper I found explains some quadrilateral rendering techniques : http://vcg.isti.cnr.it/publications/papers/quadrendering.pdf Thanks -Sid

9 21