- Inkscape Devel - Inkscape Mailman

devlibs update (r39)
by Nicolas Dufour 04 Dec '12

04 Dec '12

Hi, The devlibs have just been updated to r39 in order to activate Visio file import on Windows (Wordperfect libs have been updated, and a new visio lib has been added). Note that the modifications also required some changes in the build.xml file, and that you need to update the trunk to revision 11925 so that Inkscape compiles correctly. The 0.48.x branch doesn't use libvisio, but also needs an update (revision 9931) to take the Wordperfect changes into account. Regards. -- Nicolas

4 5

Connector Work
by Martin Owens 04 Dec '12

04 Dec '12

Hey Devs, I've got a plan for getting last year's connector work into use. I've updated the branch to the latest trunk (damn you changes!) so I'd like to get this merged in because it removes 1110 lines and replaces them with 91. So it's a big cleanup of code that was never in use: https://code.launchpad.net/~doctormo/inkscape/knot-visio This branch should maintain the same functionality as we currently have, plus a focus on the next steps to improve the functionality. Testing is required and advice for more experienced cpp developers about the use of std::map instead of a more appropriate std::list structure which I'm hoping can be picked up in merge review. The next steps are the exciting parts. I thought the idea from last year about having a generic point anchor tool was really interesting. So the way the connector work will happen is, it'll simply use other non-connector functionality to achieve everything we want. The anchor tool would insert a point path, which would be displayed on screen with either an knot-anchor which would just move along with it, or some other visual identifier which would not appear in renders. It would be selectable using the near-detection and then groupable, transformable etc because it's a real point element on the canvas. The anchor tool would be useful for a few functionalities. For the connector work we would use the point to join connectors together on canvas, as custom points on shapes when grouped with them, act as flexible points where custom paths around objects are required. This offers the best combination of features while not requiring any custom attributes or elements and doesn't require a exo-canvas def addition (which would suck IMO). It's also groovy because the amount of code will be small and use lots of existing code to achieve what we want. Best Regards, Martin Owens Note: Apologies to all the wonderful responses in the thread last year, a week after my daughter was born and I fell of the productive Internet and only now is my time freeing up a bit.

3 12

Straigthening text after pdf import
by Jelle 03 Dec '12

03 Dec '12

Hello David, You're right, it involves using both split lines and remove manual kerns in that order. If you have for instance two columns of text, the import will collect it into one <text> object with several <tspan> and place every single character using a dx and dy position. To keep the whole thing in place, you need to split the lines, then remove the manual kernings. If you do the remove manual kerns first, you end up with a single column of text with tspan. The benefit is that you can edit the text more easily, but it doesn't look remotely like the pdf document. A function that would collect grouped text and place it into a single text with tspans in a similar way would be extremely useful, even if it doesn't allow for editing that well. Text search and retrieval would become a lot easier with it. I think however that a smarter algorithm that would collect characters in the same string and place them on a baseline defined by the tspan element and it's relative position to the text tag would be a giant step towards more useable PDF text import. And it seems the same goes for PS text. BTW if the pdf import comes across unknown characters, it will use that as escape codes and create a new tspan rather than using a undefined glyph to fill the hole (have that when "()" are in the original text generated from a Chinese version windows for instance. Probably some gb2312 to Unicode conversion bug.) Anyway,.. keep up the good work, typesetting hasn't been Inkscape's strong point traditionally, so any work on that is greatly appreciated. Cheers Jelle On Mon, 03 Dec 2012 10:44:31 +0800, <inkscape-devel-request(a)lists.sourceforge.net> wrote: > Split text goes the other way - it breaks strings into smaller pieces. > Maybe > you meant text -> Remove Manual Kerns? AFAIK there is no function that > merges two > <text>'s, other than by doing it manually: cutting one and pasting it > into the end > of the other. Which will generally move the second <text>. The "split > text" extension > also moves the component pieces, and does the entire <text> not just a > selected > substring, but I guess I could modify it to be better behaved. > There is another problem with some PS files - they drop all the spaces. > So that > "this is text" becomes the character set {t,h,i,s,i,s,t,e,x,t}. The > code I'm working > on will have an option to try to reinsert the spaces based on the > letter spacing. > Regards, > David Mathog > mathog@...1176... > Manager, Sequence Analysis Facility, Biology Division, Caltech

2 1

Straigthening text after pdf import
by Jelle 03 Dec '12

03 Dec '12

Hello David, You're right, it involves using both split lines and remove manual kerns in that order. If you have for instance two columns of text, the import will collect it into one <text> object with several <tspan> and place every single character using a dx and dy position. To keep the whole thing in place, you need to split the lines, then remove the manual kernings. If you do the remove manual kerns first, you end up with a single column of text with tspan. The benefit is that you can edit the text more easily, but it doesn't look remotely like the pdf document. A function that would collect grouped text and place it into a single text with tspans in a similar way would be extremely useful, even if it doesn't allow for editing that well. Text search and retrieval would become a lot easier with it. I think however that a smarter algorithm that would collect characters in the same string and place them on a baseline defined by the tspan element and it's relative position to the text tag would be a giant step towards more useable PDF text import. And it seems the same goes for PS text. BTW if the pdf import comes across unknown characters, it will use that as escape codes and create a new tspan rather than using a undefined glyph to fill the hole (have that when "()" are in the original text generated from a Chinese version windows for instance. Probably some gb2312 to Unicode conversion bug.) Anyway,.. keep up the good work, typesetting hasn't been Inkscape's strong point traditionally, so any work on that is greatly appreciated. Cheers Jelle On Mon, 03 Dec 2012 10:44:31 +0800, <inkscape-devel-request(a)lists.sourceforge.net> wrote: > Split text goes the other way - it breaks strings into smaller pieces. > Maybe > you meant text -> Remove Manual Kerns? AFAIK there is no function that > merges two > <text>'s, other than by doing it manually: cutting one and pasting it > into the end > of the other. Which will generally move the second <text>. The "split > text" extension > also moves the component pieces, and does the entire <text> not just a > selected > substring, but I guess I could modify it to be better behaved. > There is another problem with some PS files - they drop all the spaces. > So that > "this is text" becomes the character set {t,h,i,s,i,s,t,e,x,t}. The > code I'm working > on will have an option to try to reinsert the spaces based on the > letter spacing. > Regards, > David Mathog > mathog@...1176... > Manager, Sequence Analysis Facility, Biology Division, Caltech

1 0

Knot Handles
by Martin Owens 03 Dec '12

03 Dec '12

Hey Gang, I'm trying to understand knots, I've introduced a bug with my changes that mean knots are created correctly, but then don't disapear when the focus changes. I can't find enough information about their internal operation to know if they handle this internally or if I should be implementing a LEAVE case in the item handle (which the code never had before, so how did it work before?) Best Regards, Martin Owens

1 1

Files modified by SpiroLIve
by Jabiertxo Arraiza Cenoz 02 Dec '12

02 Dec '12

All changes are in "pen-context.cpp" and "pen-context.h". Hi.

1 1

Scroll lock toggle
by Johan Engelen 30 Nov '12

30 Nov '12

Hi all, Just wondered: could we use the scroll lock toggle thingie for something? (I'm thinking about snap on/off, but there are probably much better uses for it) Cheers, Johan

2 2

Translations and r11895 bug in flow text
by Jelle 28 Nov '12

28 Nov '12

Hi Guys, Just to report that r11895 has a rather ugly bug in the flow text. After creating an initial text, I wasn't able to edit it anymore. Unfortunately launchpad is in the 3 second zone of timeouts for me in Chongqing, China and I've never been able to use it, otherwise I'd add the bug list there. Please bear with my good intention. And David, If you've ever imported a PDF file with lots of text in layouts, you may have noticed that every single character gets a position. Now that's fine until you try to change the text in any way as the text string will change, but not the positions string. In other words, you end up with garbage. The workaround for that is to use the split text extension. Which cleans up all the manual kernings nicely. Maybe that can lead you to solve your problem as well, as it seems related. Cheers Jelle > Message: 8 > Date: Mon, 26 Nov 2012 13:08:16 -0800 > From: mathog <mathog@...1176...> > Subject: Re: [Inkscape-devel] tspan Text Starts > To: <inkscape-devel(a)lists.sourceforge.net> > Message-ID: <a3d4787463b3de4b4f2a326b82cdf6ab@...2855...> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 23-Nov-2012 19:48, Martin Owens wrote: >> hey guys, >> >> I'm developing an extension to manage translations (which I do via >> launchpad and xml2po) but I'm having trouble with tspans. >> >> The problem seems to be that inkscape saves multiple values for the x >> attribute for some (not all) tspan sections. Specifying the letter >> placements is death to translations as the number and size of letters >> is >> guaranteed to be different. >> >> Is there any api way to strip out these bumbling attributes or better >> have them not appear in the first place? > > Hmm. Well, this may not be what you are after, but... > > I have been working on code to reassemble formatted, editable text from > component pieces. The idea is that something like > this in Inkscape: > > (E:bold)(=mc:no special formatting)(2:superscript) > > when present in an EMF or PS file, for instance, is represented by 3 > separately formatted text strings: > {E,=mc,2} > > These are currently read back into Inkscape as just those pieces. It > looks exactly like the original, but the pieces > are not assembled, so the whole is not editable. My code tries to > reassemble the pieces from its position, font information, etc. and > makes <test><tspan> records to match. This work is not done but the > current version does pretty well at figuring out where paragraphs start > and end, figures out the justifications and so forth, and generating > editable Inkscape SVG. It works with rotated text, but at present > cannot figure out when the first sentence of a paragraph belongs with > the remainder if the first is indented by starting it an offset (as > opposed to by using leading spaces.) > > For your purposes, would it be sufficient if after reassembly the > formatting information was discarded and just the logical > information retained? That would give you sentences and paragraphs > (super and subscripts would be problematical.) > > Regards, > > David Mathog > mathog@...1176... > Manager, Sequence Analysis Facility, Biology Division, Caltech

3 2

May I have a wiki login to fix the documentation about the windows command line
by Justin Dearing 28 Nov '12

28 Nov '12

Hello, This page does not mention inkscape.com versus inkscape.exe. I wasted many hours yesterday, eventually discovered this: http://kaioa.com/node/63 and this morning after discovering this http://stackoverflow.com/a/8030880/95195I realized my problem is I was executing inkscape.exe and not inkscape from the command prompt. I'd like to clarify the issue so others do not go down the same path. Justin

3 2

Obscure kerning issue
by mathog 27 Nov '12

27 Nov '12

My code to reassemble text from pieces written to EMF files is working great now except for one nagging problem, which only shows up in a few special cases involving manually kerned text. Consider these three sequences: 1. <period><space><A>(hkern + 3.75)<vertical bar> 2. <period><A>(hkern + 3.75)<vertical bar> 3. <period><space><A><vertical bar> The individual pieces written to the EMF (not reassembled) map exactly onto the originals, so there is no problem in the output coordinates. However, when reassembled into a single <text><tspan> complex (2) and (3) are still OK, but (1) is off, with the vertical bar offset leftwards towards the "A", yet the ". A" is exactly where it should be. I have tracked the problem down to the extent that I know Inkscape's display code is calculating the width of ". A" differently, when manual kerning is present, than just the sum of the advances of those characters. (Logic: the complex looks like <text><tspan></tspan><tspan</tspan><text> and the second tspan pair has a dx value calculated by subtracting from the start position of the fragment [which is correct] the start position of the previous fragment [which is also correct] plus the width of the previous fragment [which must therefore not be correct]. Changing dx to match the original kerning fixes the problem - also consistent with the calculated width not matching that from Freetype2.) Inkscape seems not to be using Freetype Kerning corrections of this type: FT_Get_Kerning( fsp->face, prev_glyph_index, glyph_index, kern_mode, &akerning ) I tried adding that, and while there was a correction for " A", it only half fixed the problem. Besides, I could not find a call to FT_Get_Kerning anywhere in the source. (It might be called indirectly by some other library.) This was all done on one machine, so it isn't a case of mismatched fonts between machines. Anybody have a thought on what Inkscape might be doing to come up with a different string width in this particular instance? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 1