[Chart] Fwd: Fwd: [diagrams] Re: [GSoC 2013] Progress - Porting Charts to Diagrams
Jan Bracker
jan.bracker at googlemail.com
Mon Aug 12 16:19:28 BST 2013
Hello everybody,
I spent last week working on the SVG font to Haskell code converter. I got
a running version here [0]. It's in the "font-converter" directory. While
writing and testing it I ran into a few problems:
When I output all data into one single big file it does not compile
(actually it does seem to compile but after 25 minutes I gave up on letting
it finish). So I now divide the data into several modules. After doing so
everything compiled, but each of the modules containing the outlines took
about 1 to 2 minutes to compile although each only contained about 30
glyphs. For small fonts this was bearable but unpleasant, when converting
Linux Libertine I would have spent 2 hours compiling it. So right now I do
not hard code the glyphs paths into code anymore and instead added code to
generate the outline from the string encoded paths during run time. I am
not sure if this still solves the performance problems we have when
rendering. I am going to check on that soon. If this does not help with the
performance problem I would try to rewrite the path parser using attoparsec
or similar libraries.
Besides this compilation and performance issue, we can now include fonts
that do not need IO to load.
Greets
Jan
[0]: https://github.com/jbracker/SVGFonts/tree/font-converter
2013/8/5 Jan Bracker <jan.bracker at googlemail.com>
> Hello everybody,
>
> this weeks changes are not to many. I only fixed the last bug on my list.
> It was caused by not correctly setting the line, fill and font style to
> their default value before starting to render in the backend. This is fixed
> now and both backends work well. There are some minor rendering differences
> which appeared after merging with the new lens code. I have no idea why
> they appear, but again they are not visible with the naked eye. You can
> find the latest code here [0].
>
> The further plan: Speed is an issue when using SVGFonts to render text.
> That is why we are planning to write a translator that creates Haskell
> source from an SVG font file. This way things should speed up, because the
> font does not have to be read during runtime anymore and we also hope the
> constant expression optimizations of the compiler also lead to speedups.
> Besides speed this also solves the other problem of hidden IO in SVGFonts,
> it will allow pure access to the included fonts.
> I searched through Hackage to find Haskell source generators and my only
> hits were template Haskell, haskell-src [1] and haskell-src-exts [2]. I
> think I will use haskell-src-exts, since it is more up to date then
> haskell-src and I do not see the necessity for this utility to depend on
> something as complex as template Haskell.
>
> Greets
> Jan
>
> [0]:
> https://github.com/jbracker/haskell-chart/tree/9d5cc6c1c4c7e8d86273bd0e1010daa00248db09
> [1]: http://hackage.haskell.org/package/haskell-src
> [2]: http://hackage.haskell.org/package/haskell-src-exts
>
>
> 2013/8/1 Tim Docker <tim at dockerz.net>
>
>> My week is not turning out very well :-(
>>
>> I will be a bit late tonight. I'm sure you can continue without me.
>>
>> Sorry!
>> On 31 Jul 2013 21:45, "Brent Yorgey" <byorgey at seas.upenn.edu> wrote:
>>
>>> Yes, I've been quite impressed with Jan's progress and am excited to
>>> try it out! I will indeed be available then and would be happy to
>>> discuss text handling. I will have to leave at 12:00UTC but that
>>> should give us plenty of time for discussion.
>>>
>>> -Brent
>>>
>>> On Wed, Jul 31, 2013 at 07:16:37AM +1000, Tim Docker wrote:
>>> > Hi Brent,
>>> >
>>> > Jan has made great progress, and has charts more or less up and
>>> > running atop diagrams (see below).
>>> >
>>> > Currently the text handling is done outside the diagrams libs, just
>>> > rendering the paths. It would be good if we could discuss with you
>>> > potential approaches for improving the diagrams native text support.
>>> >
>>> > Is there any chance you may be around on IRC at 11:00UTC on thursday?
>>> > If that time doesn't suit, I'm sure we can arrange another soon.
>>> >
>>> > Tim
>>> >
>>> >
>>> > On 30/07/13 22:25, Jan Bracker wrote:
>>> > >Tomorrow 9:30pm sounds good for me.
>>> > >
>>> > >Jan
>>> > >
>>> > >
>>> > >2013/7/30 Tim Docker <tim at dockerz.net <mailto:tim at dockerz.net>>
>>> > >
>>> > > Hi,
>>> > >
>>> > > I'm sorry for the late notice, but I won't be able to make our IRC
>>> > > meeting this tonight.
>>> > >
>>> > > Either tomorrow at 9:30pm, or Thursday at 9:00pm are fine with me.
>>> > >
>>> > > Tim
>>> > >
>>> > >
>>> > > On 30/07/13 01:40, Jan Bracker wrote:
>>> > >> Hello everybody,
>>> > >>
>>> > >> here the latest progress on the project:
>>> > >>
>>> > >> - While using SVGFonts I fixed a few minor bugs in it.
>>> > >> - The "ToRenderable" type class is reintroduced, because the type
>>> > >> complications are not there anymore.
>>> > >> - Some clean up and more specific documentation (especially
>>> paths).
>>> > >> - Switched from data-default to data-default-class.
>>> > >> - Standard alignment functions are not provided instead of
>>> > >> redifined in each backend.
>>> > >> - Updated the diagrams backend to use the HEAD of diagrams
>>> > >> instead of the hackage version.
>>> > >> - All my work until 25th of July has been merged into the main
>>> > >> charts repo!
>>> > >> - Worked on the font support in the diagrams backend. This works
>>> > >> well now.
>>> > >> - Included standard fonts in the diagrams backend package. This
>>> > >> also includes additional versions to support bold and italic
>>> fonts.
>>> > >>
>>> > >> The current head is "stable", except for the text metrics [1]. I
>>> > >> figured out the metrics. Some issues I still have:
>>> > >>
>>> > >> - For some reason SVGFonts seems to be rendering fonts of same
>>> > >> size considerably smaller then cairo. Not sure what the reason
>>> > >> is. Going to double check on this.
>>> > >> - One of the tests is still missing some lines.
>>> > >> - Quality of font rendering is notably worse with SVGFonts. I do
>>> > >> not think this can really be improved except by adding native
>>> > >> text rendering to diagrams (+ font metrics). Though, when using
>>> > >> sans-serif and monospace fonts quality is acceptable (Adobe seems
>>> > >> to be doing good work with Source Sans Pro and Source Code Pro).
>>> > >> Maybe I will check for an alternative serif font, though it will
>>> > >> be hard to beat the character support of Linux Libertine.
>>> > >>
>>> > >> Greetings
>>> > >> Jan
>>> > >>
>>> > >> [1]:
>>> > >>
>>> https://github.com/jbracker/haskell-chart/tree/e01257cda11d9832ac9a3c7af424c02bd83cb1a2
>>> > >>
>>> > >>
>>> > >> 2013/7/23 Stephen Tetley <stephen.tetley at gmail.com
>>> > >> <mailto:stephen.tetley at gmail.com>>
>>> > >>
>>> > >> Hi Jan
>>> > >>
>>> > >> In the PostScript world, glyph metrics are given as 1/1000 of
>>> > >> a point size. One would hope SVG might follow this lead.
>>> > >>
>>> > >> Although out-of-date in the TrueType world, the AFM spec from
>>> > >> Adobe is a readable (and skimmable) introduction to glyph
>>> > >> metrics and still a worthwhile reference.
>>> > >>
>>> > >>
>>> http://partners.adobe.com/public/developer/en/font/5004.AFM_Spec.pdf
>>> > >>
>>> > >> Best wishes
>>> > >>
>>> > >> Stephen
>>> > >>
>>> > >> On 23 July 2013 11:07, Jan Bracker
>>> > >> <jan.bracker at googlemail.com
>>> > >> <mailto:jan.bracker at googlemail.com>> wrote:
>>> > >>
>>> > >>
>>> > >>
>>> > >> Aside of that I also noticed that the text metric
>>> > >> information in SVGFonts are not given in device
>>> > >> coordinates. Am I right in assuming they are given in
>>> > >> 1000em, because the value "units-per-em" says 1000? If
>>> > >> that is right I will try to dig my way through the
>>> > >> textSVG' function to find out how to convert that into
>>> > >> device coordinates.
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >> _______________________________________________
>>> > >> Chart mailing list
>>> > >> Chart at projects.haskell.org <mailto:Chart at projects.haskell.org>
>>> > >> http://projects.haskell.org/cgi-bin/mailman/listinfo/chart
>>> > >
>>> > >
>>> >
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/chart/attachments/20130812/dea389cd/attachment.htm>
More information about the Chart
mailing list