<div class="gmail_quote">On 4 July 2010 05:08, Walter Bender <span dir="ltr"><<a href="mailto:walter.bender@gmail.com" target="_blank">walter.bender@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Sat, Jul 3, 2010 at 7:44 AM, Tim McNamara<br>
<<a href="mailto:paperless@timmcnamara.co.nz" target="_blank">paperless@timmcnamara.co.nz</a>> wrote:<br>
> Hi Walter, et all,<br>
> This patch should go most of the way to fixing the bug. However, I haven't<br>
> tested it locally & it contains a few assumptions about what the SVG files<br>
> look like that that it's processing. I'm also not 100% sure about the<br>
> elementtree implementation of ElementTree (am used to lxml). That said, I<br>
> would like your feedback about whether you consider this to be an<br>
> appropriate way to approach the problem.<br>
<br>
</div>I don't know much about ElementTree, but the patch itself looks OK.<br>
What I don't understand is how the textbox width is determined. How do<br>
we know how long to make the strings?<br></blockquote><div><br></div><div>My patch includes the max_len argument twice, for convenience only. <font class="Apple-style-span" face="'courier new', monospace">process_text_in_svg </font><font class="Apple-style-span" face="arial, helvetica, sans-serif">passes those arguments to </font><font class="Apple-style-span" face="'courier new', monospace">process_text_in_svg, </font><font class="Apple-style-span" face="arial, helvetica, sans-serif">which itself passes those arguments to </font><font class="Apple-style-span" face="'courier new', monospace">split_at_len</font><font class="Apple-style-span" face="arial, helvetica, sans-serif">.</font> My thought was that it would enable the functions to be accessed externally. Then again, I should use objects if I would like to maintain state like this.</div>
<div><br></div><div>As far as how the width is calculated, I've created an arbitrary cut-off at 50 characters. This is used by split_at_len. It would be better to draw an inference about the available space left on the page from the element's x/y position and the height/width of the whole page. However, I consider this patch an intermediate step & patch submission as a pit stop to get review comments.</div>
<div><br></div><div>Relationship between three functions</div><div> <font class="Apple-style-span" face="'courier new', monospace">process_text_in_svg</font> accepts whole SVG file/string, calls <font class="Apple-style-span" face="'courier new', monospace">process_svg_text_element</font> on <text> tags, returns SVG as a string</div>
<div> <span class="Apple-style-span" style="font-family: 'courier new', monospace; ">process_svg_text_element </span><font class="Apple-style-span" face="arial, helvetica, sans-serif">accepts a list of Element objects, calling </font><font class="Apple-style-span" face="'courier new', monospace">split_at_len</font><font class="Apple-style-span" face="arial, helvetica, sans-serif"> on their content, returning the Element</font></div>
<div> <font class="Apple-style-span" face="'courier new', monospace">split_at_len</font> accepts single string, returns list of strings</div><div> </div><div>I'll work on an OO implementation on this. It'll add flexibility & clarity.</div>
<div><br></div><div>-Tim.</div><div><br></div><div><br></div></div>