<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 15, 2017 at 3:51 AM, Adrian Johnson <span dir="ltr"><<a href="mailto:ajohnson@redneon.com" target="_blank">ajohnson@redneon.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15/09/17 09:29, Matthias Clasen wrote:<br>
> On Thu, Sep 14, 2017 at 5:54 PM, Adrian Johnson <<a href="mailto:ajohnson@redneon.com">ajohnson@redneon.com</a><br>
</span><span class="">> <mailto:<a href="mailto:ajohnson@redneon.com">ajohnson@redneon.com</a>>> wrote:<br>
><br>
>     On 15/09/17 05:52, Matthias Clasen wrote:<br>
>     > On Thu, Sep 14, 2017 at 12:37 PM, Behdad Esfahbod<br>
>     > <<a href="mailto:behdad.esfahbod@gmail.com">behdad.esfahbod@gmail.com</a> <mailto:<a href="mailto:behdad.esfahbod@gmail.com">behdad.esfahbod@gmail.<wbr>com</a>><br>
</span>>     <mailto:<a href="mailto:behdad.esfahbod@gmail.com">behdad.esfahbod@gmail.<wbr>com</a><br>
<span class="">>     <mailto:<a href="mailto:behdad.esfahbod@gmail.com">behdad.esfahbod@gmail.<wbr>com</a>>>> wrote:<br>
>     ><br>
>     >     Thanks Matthias.  I took a look at the patch.  Looks good!  Minor<br>
>     >     comments:<br>
>     ><br>
>     >     - Moving the format towards CSS by default (no comma, no equal sign;<br>
>     >     just spaces!) while accepting both is what I do in HarfBuzz. Maybe<br>
>     >     advertise the same here,  UPDATE: I was wrong.  CSS uses comma as<br>
>     >     well.  It's the equal sign that they don't use, they use space.  We<br>
>     >     should accept both.<br>
>     ><br>
>     ><br>
>     > I've made the parser a bit more flexible. It now accepts variations like<br>
>     ><br>
>     > wdth=200,wght=300<br>
>     > wdth 200, wght=300<br>
>     > wdth 200 , wght 300<br>
><br>
>     Does it work with decimal commas?<br>
><br>
><br>
> The patch currently uses strtod, so yes, it will parse floating point<br>
> numbers, but decimal separators spell trouble.<br>
> I could rewrite it to use strtod_l, if that is ok to use in cairo.<br>
<br>
</span>So what happens on platforms where strtod_l is not available?<br></blockquote><div><br></div><div>Then parsing fails.  But then again, this is only hooked up in the FreeType backend right now...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The function decode_real() in cairo-cff-subset.c has code for locale<br>
independent parsing of floating-point numbers. Maybe that could be<br>
factored out into separate function and reused.<br></blockquote><div><br></div><div>Sounds good.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Where is the variations text string normally expected to come from? I<br>
can see the code reading the FC_FONT_VARIATIONS property but I can't<br>
find this in the current fontconfig git. Where is this documented?<br></blockquote><div><br></div><div>I have a branch that adds that.  I'll finish it today or tomorrow and post.  You can wait till then.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is the text string supplied to cairo_font_options_set_<wbr>variations()<br>
likely to be generated by sprintf or is it always read from an external<br>
source in C locale format?<br>
<br>
We really need a test case for this. It is hard to review code I can't test.<br>
</blockquote></div><br></div><div class="gmail_extra">In a day or two I'll have cairo piece hooked-up in hb-view, and then cairo and fontconfig bits in pango-view.  That should simplify testing.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">behdad<br><a href="http://behdad.org/" target="_blank">http://behdad.org/</a></div>
</div></div>