[Chart] Fwd: Fwd: [diagrams] Re: [GSoC 2013] Progress - Porting Charts to Diagrams
Jan Bracker
jan.bracker at googlemail.com
Mon Aug 19 14:58:12 BST 2013
Hello everybody,
last week I:
- Fixed some bugs in SVGFonts.
- Added a interface to preload customs fonts in the diagrams backend.
- Fixed a bug with filling multiple sub trails in the diagrams backend.
- I worked on fixing the bug of charts being rendered upside down in SVGs
when using diagrams-svg. I got a solution for this but it seems like a hack
and I would like to discuss this [0].
- I added nice utilities to render SVG and EPS files directly using the
diagrams backend. This pulls in some other dependencies but as it is the
major use case you would want them anyway.
I did not really work on the font converter to much. Instead I started
profiling the tests to see where the application spends most of its time.
According to the profiling information when running the DiagramsCairo.hs
[1] test about 45% of the computation time is spent inside the textSVG' /
makeString function [2]. When trying to analyse the sub expressions I found
out that 90% of that time is spent inside the call to scaleY. I am not sure
where to go from here, because it seems like most of the computation is due
to diagrams arithmetic. Only 10% of the time is spent with actual rendering
and 15% with extracting the characters from the string.
Greets
Jan
[0]:
https://groups.google.com/d/topic/diagrams-discuss/C2_0CFQNd80/discussion
[1]:
https://github.com/timbod7/haskell-chart/blob/master/chart-tests/tests/DiagramsCairo.hs
[2]:
https://github.com/diagrams/SVGFonts/blob/master/src/Graphics/SVGFonts/ReadFont.hs#L68
2013/8/12 Jan Bracker <jan.bracker at googlemail.com>
> 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/20130819/c48ab066/attachment.htm>
More information about the Chart
mailing list