[Chart] Fwd: Fwd: [diagrams] Re: [GSoC 2013] Progress - Porting Charts to Diagrams
Jan Bracker
jan.bracker at googlemail.com
Mon Sep 16 13:33:50 BST 2013
Hello Everybody,
the refactoring of Layout1 was finished over the past week. Here the
changes:
- AxisVisibility type was introduced to determine which parts of an axis
shall be displayed at all. It contains three flags to turn the axis line,
labels and ticks on or off.
- _laxis_visible was removed from LayoutAxis since its function is now
replaced by the new AxisVisibility type.
- The compression of x labels was removed from StackedLayouts. Each Layout
now controls which axis are displayed itself. Also StackedLayout supports
both types of layout.
- All tests were modified to work with the new interface and produce the
same charts as before.
- Also updated all documentation on code that I touched.
The work can be seen in the layout-refactor branch [0]. This work together
with the font embedding things is in progress of being merged with the rest
of chart as of now [1].
As the Google Summer of Code is coming to an end this week I guess this
will be my last report.
Greets
Jan
[0]: https://github.com/jbracker/haskell-chart/tree/layout-refactor
[1]: https://github.com/timbod7/haskell-chart/pull/10
2013/9/9 Jan Bracker <jan.bracker at googlemail.com>
> 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/20130916/250228cf/attachment-0001.htm>
More information about the Chart
mailing list