More tests/testing using Python?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

More tests/testing using Python?

Thomas Shinnick
I hate things sneaking up on me.  I love tests that say I haven't again broken things broken before.  So I've been thinking...

If I started a simple-minded test in Python scripting that checked whether "remove overlap" seems to work, could y'all point out the test fonts and particular characters illustrating (old) bugs. 

I'm thinking that something as simple as "how many splines are there _now_?" could be a helpful test. 

For example, one of my glyphs with overlapping strokes, sampling data using a Python script tells me the glyph starts out with 6 splines and they're all closed (b/c individually expanded strokes)

  #contours:         6
  boundBox:          (-13.6533203125, 486.3466796875, 313.6533203125, 813.6533203125)
  isEmpty():         0
  is_quadratic:      0
  selfIntersects():  True
    closed:          1
    closed:          1
    closed:          1
    closed:          1
    closed:          1
    closed:          1

After applying "remove overlaps" I get the expected number of splines, now only 4 due to overlap removal (yay!) but... some of them aren't closed splines (boo!).

  #contours:         4
  boundBox:          (-12.5, 487.5, 312.5, 812.5)
  isEmpty():         0
  is_quadratic:      0
  selfIntersects():  True
    closed:          0
    closed:          1
    closed:          0
    closed:          1

Just a simple programmed test: how many to begin with, how many after applying operation, are they all closed, ... and one could include an indication of what the points ought to be (thus how the spline ought to 'look')

Hey, in this particular erroring case, the boundingBox for at least one resulting 'bad' spline would be way wrong - much too broad from top to bottom - again an easy check.

It'd at least be a good "smoke test", yes?

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Fontforge-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Reply | Threaded
Open this post in threaded view
|

Re: More tests/testing using Python?

Frank Trampe
The number of splines or points may not be constant even among functional overlap removers, depending upon how many intersections a pair of coincident segments produce and how aggressively we consolidate close intersections and segment ends during processing. We currently keep all generated intersections and end points that occur on surviving monotonics as far as I know, but we could eliminate non-end points on lines without breaking things, and other software packages may do that.

Looking for unclosed splines is good. As currently designed, the Fontforge overlap removal system expects to eliminate any unclosed paths before proceeding to the later stages of the process. If open paths survive, something is wrong.

Checksumming a low-resolution rendering of each glyph might also be useful.



On Tue, Jul 15, 2014 at 7:03 PM, Thomas Shinnick <[hidden email]> wrote:
I hate things sneaking up on me.  I love tests that say I haven't again broken things broken before.  So I've been thinking...

If I started a simple-minded test in Python scripting that checked whether "remove overlap" seems to work, could y'all point out the test fonts and particular characters illustrating (old) bugs. 

I'm thinking that something as simple as "how many splines are there _now_?" could be a helpful test. 

For example, one of my glyphs with overlapping strokes, sampling data using a Python script tells me the glyph starts out with 6 splines and they're all closed (b/c individually expanded strokes)

  #contours:         6
  boundBox:          (-13.6533203125, 486.<a href="tel:3466796875" value="+13466796875" target="_blank">3466796875, 313.6533203125, 813.6533203125)
  isEmpty():         0
  is_quadratic:      0
  selfIntersects():  True
    closed:          1
    closed:          1
    closed:          1
    closed:          1
    closed:          1
    closed:          1

After applying "remove overlaps" I get the expected number of splines, now only 4 due to overlap removal (yay!) but... some of them aren't closed splines (boo!).

  #contours:         4
  boundBox:          (-12.5, 487.5, 312.5, 812.5)
  isEmpty():         0
  is_quadratic:      0
  selfIntersects():  True
    closed:          0
    closed:          1
    closed:          0
    closed:          1

Just a simple programmed test: how many to begin with, how many after applying operation, are they all closed, ... and one could include an indication of what the points ought to be (thus how the spline ought to 'look')

Hey, in this particular erroring case, the boundingBox for at least one resulting 'bad' spline would be way wrong - much too broad from top to bottom - again an easy check.

It'd at least be a good "smoke test", yes?

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Fontforge-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fontforge-devel



------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Fontforge-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Reply | Threaded
Open this post in threaded view
|

Re: More tests/testing using Python?

Dave Crossland
In reply to this post by Thomas Shinnick

Great idea!! :)

On 15 Jul 2014 20:04, "Thomas Shinnick" <[hidden email]> wrote:
I hate things sneaking up on me.  I love tests that say I haven't again broken things broken before.  So I've been thinking...

If I started a simple-minded test in Python scripting that checked whether "remove overlap" seems to work, could y'all point out the test fonts and particular characters illustrating (old) bugs. 

I'm thinking that something as simple as "how many splines are there _now_?" could be a helpful test. 

For example, one of my glyphs with overlapping strokes, sampling data using a Python script tells me the glyph starts out with 6 splines and they're all closed (b/c individually expanded strokes)

  #contours:         6
  boundBox:          (-13.6533203125, 486.<a href="tel:3466796875" value="+13466796875" target="_blank">3466796875, 313.6533203125, 813.6533203125)
  isEmpty():         0
  is_quadratic:      0
  selfIntersects():  True
    closed:          1
    closed:          1
    closed:          1
    closed:          1
    closed:          1
    closed:          1

After applying "remove overlaps" I get the expected number of splines, now only 4 due to overlap removal (yay!) but... some of them aren't closed splines (boo!).

  #contours:         4
  boundBox:          (-12.5, 487.5, 312.5, 812.5)
  isEmpty():         0
  is_quadratic:      0
  selfIntersects():  True
    closed:          0
    closed:          1
    closed:          0
    closed:          1

Just a simple programmed test: how many to begin with, how many after applying operation, are they all closed, ... and one could include an indication of what the points ought to be (thus how the spline ought to 'look')

Hey, in this particular erroring case, the boundingBox for at least one resulting 'bad' spline would be way wrong - much too broad from top to bottom - again an easy check.

It'd at least be a good "smoke test", yes?

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Fontforge-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fontforge-devel


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Fontforge-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fontforge-devel