[Chart] Fwd: Fwd: [diagrams] Re: [GSoC 2013] Progress - Porting Charts to Diagrams

Brent Yorgey byorgey at seas.upenn.edu
Tue Aug 20 01:18:00 BST 2013 

On Mon, Aug 19, 2013 at 03:58:12PM +0200, Jan Bracker wrote:
> 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.

Very interesting.  I profiled another large example during Hac Phi and
found that a lot of time was being spent in rotateBy.  So it seems
that perhaps Transformations are somehow implicated in performance
issues.  The way we represent Transformations certainly carries some
overhead.  I am not sure how to go about optimizing things.  Any
suggestions or help are most welcome.

-Brent

> 
> 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
> >>>> > >
> >>>> > >
> >>>> >
> >>>>
> >>>
> >>
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups "diagrams-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to diagrams-discuss+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

More information about the Chart mailing list