[Chart] Fwd: Fwd: [diagrams] Re: [GSoC 2013] Progress - Porting Charts to Diagrams
Jan Bracker
jan.bracker at googlemail.com
Mon Sep 9 17:06:16 BST 2013
Hello Everybody,
the changes to SVGFonts and diagrams-svg are now merged with their master
branches. Some time soon we will release a new version of Charts containing
the optimized SVG feature.
I worked on refactoring the Layout1 type of Charts over the past week.
Currently this is one structure that combines the ability to render one Y
axis or two Y axis in the same plot. Tim suggested to divide it into Layout
(for ploting one y axis over one x axis) and LayoutLR (for ploting two
different y axis over one x axis). This should make the API a bit cleaner,
ensure that the top and bottom axis (which refer to the same data) will
always have the same labels and ticks and it also enables two Y axis with
different type, which is not possible with the old Layout1. This is work in
progress and can be seen in the layout-refactor [0] branch of my fork.
Greets
Jan
[0]: https://github.com/jbracker/haskell-chart/tree/layout-refactor
2013/9/2 Jan Bracker <jan.bracker at googlemail.com>
> 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/20130909/fa315c1e/attachment-0001.htm>
More information about the Chart
mailing list