[Chart] Fwd: Fwd: [diagrams] Re: [GSoC 2013] Progress - Porting Charts to Diagrams
Jan Bracker
jan.bracker at googlemail.com
Mon Sep 2 16:35:46 BST 2013
Hello everybody,
I worked on embedding fonts into the output SVGs of Diagrams to reduce the
time it takes to render charts and the size of output SVGs. This was a
success! Using the standard SVG output without embedded fonts all tests run
in about 50 seconds, while using the embedded fonts they run in about 38
seconds on my machine. So we are talking about as speedup of ~20%. The
output SVGs also got smaller in size. Most lost ~50% of their size,
depending on how much text they actually use. None of the tests is bigger
then a megabyte anymore.
The sources for this change can be found in the font-embedding branch of
chart-diagrams [0]. I also had to change diagrams-svg [1] and SVGFonts [2]
for this to work (their changes are also in the branch font-embedding). I
will soon merge this changes back to master and send out a few pull
requests. chart-diagrams now offers four functions to use this
optimization: renderableToEmbeddedFontSVGFile
and renderableToEmbeddedFontSVG (together with their primed variant) [3].
Here a detailed list of what I have done over the past days:
- Fixed rendering issues with chart-diagrams when rendering SVGs (they were
upside down and scaled weird).
- runBackend' now takes a switch to decide whether it should render using
the native text or with SVGFonts, it also collects used characters when
rendering native.
- Added a WriteFont module to SVGFonts that enables it to write a read font
back to SVG.
- Enabled to use the font family name of the default fonts in addition to
their generic names.
- Added an approximation of text alignments in diagrams-svg (was not
implemented yet).
- Worked on correct support of line miter limits in diagrams.
- Fixed a bug with stacked clippings in diagrams-svg.
- Fixed text rendering issues with the chart-diagrams backend.
- Added a hook in diagrams-svg font to add custom definitions to produces
SVG files (so I can write the fonts in the files).
- Added functions that render to SVG and actually embed the fonts in
chart-diagrams.
Greets
Jan
[0]:
https://github.com/jbracker/haskell-chart/tree/font-embedding/chart-diagrams
[1]: https://github.com/jbracker/diagrams-svg/tree/font-embedding
[2]: https://github.com/jbracker/SVGFonts/tree/font-embedding
[3]:
https://github.com/jbracker/haskell-chart/blob/font-embedding/chart-diagrams/Graphics/Rendering/Chart/Backend/Diagrams.hs#L149
2013/8/19 Jan Bracker <jan.bracker at googlemail.com>
> 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/20130902/e999351a/attachment-0001.htm>
More information about the Chart
mailing list