shadowfacts/fonttools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
177 Commits 1 Branch 0 Tags
Commit Graph

177 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Cosimo Lupo
826b790147 [ufo] minor refactor 2016-09-19 13:10:57 +01:00
Cosimo Lupo
f2e962c78f [ufo] don't check glyph names in glyphs_to_quadratic 2016-08-12 16:00:20 +01:00
Cosimo Lupo
e7854e5039 [ufo] add glyph[s]_to_quadratic to convert (1+ compatible) glyphs 
This was requested in https://github.com/googlei18n/cu2qu/issues/26

Plus:
- do not modify input glyphs unless they contain one cubic curve;
- make public functions return True/False to signal that the input
  was modified or not (eg. no curves, or all quadratic)
 2016-08-12 15:30:51 +01:00
Behdad Esfahbod
ab3c0f82e6 Merge pull request #44 from googlei18n/more-optimizations 
More optimizations
 2016-08-01 18:11:49 -07:00
Behdad Esfahbod
c53ea86826 Use a generator for cubics[] 
Not huge fan of it, but shows slight speedup, and is "Pythonic".
 2016-08-01 18:10:16 -07:00
Behdad Esfahbod
9db52c9483 Avoid some more work 
Saves another 7%.  Somehow I failed to push this to the last batch.
 2016-08-01 14:34:41 -07:00
James Godfrey-Kittle
f5d067db86 Merge pull request #42 from googlei18n/fix-tests 
Fix tests
 2016-08-01 14:17:31 -07:00
James Godfrey-Kittle
fc5f5d194d Fix tests 2016-08-01 14:15:26 -07:00
Behdad Esfahbod
33478a9e49 Merge pull request #40 from googlei18n/never-say-never 
Never say never
 2016-08-01 14:11:46 -07:00
James Godfrey-Kittle
daaa1bd06f Report number of segments in result, not points (#41) 
For some reason, I was subtracting 1 from the spline lengths in the
test report. Not sure why that is, so I've assumed it was wrong (and
now we subtract 2 to get the length in number of segments).
 2016-08-01 14:08:26 -07:00
Behdad Esfahbod
17b034c904 In curves_to_quadratic(), avoid some more work 
When a curve fails to convert at a certain n, keep increasing n for
this curve until a fit found.  Saves another 7% in the benchmark.
 2016-07-29 20:31:38 -07:00
Behdad Esfahbod
06eb980a0c Split off case of n=1 into its own function 
Looks like changes like this don't have measurable performance
penalty, but they do help with analyzing profile output to see
which branch (n=1 or n!=1) takes more time.
 2016-07-29 20:31:38 -07:00
Behdad Esfahbod
96eb3baa15 Add specialization of split_cubic_into_n() for n=6 
...by calling split_cubic_into_three() twice.  Gives another 5..9%
speedup.  The thing is, while higher n values are lower-frequency,
the savings are also bigger.  So the two offset out.
 2016-07-29 20:31:38 -07:00
Behdad Esfahbod
6d811003ed Add specialization of split_cubic_into_n() for n=4 
...by calling split_cubic_into_two() twice.  Gives another 5% speedup.
 2016-07-29 20:31:38 -07:00
Behdad Esfahbod
44235274cd Remove variable that was used once. 2016-07-29 20:31:38 -07:00
Behdad Esfahbod
d201c2c28b Merge pull request #38 from googlei18n/one-last-optimization 
One last optimization
 2016-07-28 18:04:57 -07:00
Behdad Esfahbod
f899c8ccf8 Combine two more loops 
Another 10% speedup.
 2016-07-28 17:37:18 -07:00
Behdad Esfahbod
c5a17bb055 Shuffle code in cubic_approx_spline() a bit 2016-07-28 17:10:49 -07:00
Behdad Esfahbod
b305ef49be Another micro-optimization 2016-07-28 16:31:30 -07:00
Behdad Esfahbod
40ebe85d9e Move special-cases of split_cubic_into_n() into it 
Surprisingly this doesn't seem to slow down, but also slightly
speed up.
 2016-07-28 16:25:58 -07:00
Behdad Esfahbod
ede89847a7 Apply review changes from https://github.com/googlei18n/cu2qu/pull/37 2016-07-28 16:12:00 -07:00
Behdad Esfahbod
701105098b Merge pull request #37 from googlei18n/break-early 
Break early
 2016-07-28 16:10:13 -07:00
Behdad Esfahbod
223450e8d7 Break out of conversion loop early if a curve fails to convert 
Makes the compatible-conversion about 40% faster.
 2016-07-28 14:41:33 -07:00
Behdad Esfahbod
39fbd9faba [benchmark] Make output more compact 
Also, are the min numbers really useful?
 2016-07-28 14:41:33 -07:00
Behdad Esfahbod
54104319f9 Another theoretical optimization 2016-07-28 13:57:17 -07:00
Behdad Esfahbod
de9b9ba3e1 Reduce code duplication 2016-07-28 13:51:11 -07:00
Behdad Esfahbod
77c913ba61 Add keyword-argument hack for 2/3 as well 2016-07-28 13:44:41 -07:00
Behdad Esfahbod
d357503806 Merge pull request #36 from googlei18n/cleanup 
Cleanup
 2016-07-28 13:35:04 -07:00
James Godfrey-Kittle
d87bbe25fd Typo 2016-07-28 12:51:08 -07:00
James Godfrey-Kittle
c0b6ed92e3 Update/add some rudimentary comments 2016-07-28 12:32:29 -07:00
James Godfrey-Kittle
f7b9ebba06 Move error classes, dot function to top of file 2016-07-28 12:12:22 -07:00
James Godfrey-Kittle
5db64c55aa More vertical whitespace 
Style guide says two blank lines between top level functions.
 2016-07-28 12:09:52 -07:00
James Godfrey-Kittle
152baa88a5 No lines over 80 characters 
This meant going back on my horizontal whitespace around operators
stance, but in this case I think it looks better to reduce whitespace
than to break up the line.
 2016-07-28 12:07:44 -07:00
James Godfrey-Kittle
65befad036 Update some comments 2016-07-28 12:03:53 -07:00
James Godfrey-Kittle
8dc57da4ae Remove unnecessary parentheses 2016-07-28 12:00:13 -07:00
James Godfrey-Kittle
e5cf42545b Variable names 
In some cases these changes were made for clarity, in some cases more
just for consistency. Anyways we should now have mostly consistent and
reasonably clear variable names everywhere.
 2016-07-28 11:56:14 -07:00
James Godfrey-Kittle
3225b1e249 No camelcase 
I guess this was done for consistency with names in FontTools, but I
gotta say it was bugging me that some functions in this module used
underscores and some used camelcase. Style guide says underscores.
 2016-07-28 11:41:42 -07:00
James Godfrey-Kittle
ccb1a73edd Factor before variable when no whitespace 
This is just a consistency thing; see code above change.
 2016-07-28 11:37:08 -07:00
James Godfrey-Kittle
746873233b More whitespace around binary operators 
This is very subjective, but my preference is more whitespace.
Generally the only place I didn't put in whitespace was for
multiplication within statements that also contained additions,
without parentheses.
 2016-07-28 11:35:32 -07:00
James Godfrey-Kittle
847d12180b Get rid of unnecessary decimal points 
We import division from __future__, so float division happens by
default.
 2016-07-28 11:21:47 -07:00
James Godfrey-Kittle
569872be21 Merge pull request #35 from googlei18n/ufo-benchmark 
UFO benchmark module
 2016-07-28 10:58:05 -07:00
James Godfrey-Kittle
2a8eb7993e Revert "Change expected test results for travis" 
This reverts commit 79beda96a4e26d5d1778f24de673cf14c6bda1ac.

Apparently now Travis expects what my local machine expects. I swear,
Travis is messing with me....
 2016-07-27 17:02:44 -07:00
James Godfrey-Kittle
d864619c8b Typo 2016-07-27 16:52:19 -07:00
James Godfrey-Kittle
4d72a44d35 Remove unused code 2016-07-27 16:52:09 -07:00
James Godfrey-Kittle
a91108185f Correct single-segment approximation return 2016-07-27 16:51:45 -07:00
James Godfrey-Kittle
ea08338878 UFO benchmark module 2016-07-27 16:50:57 -07:00
Behdad Esfahbod
8a9cf24429 Fix splitting into one quadratic 
Ouch, broke it in 64af3ad4a87 originally.  Caught by James.
 2016-07-27 18:53:09 -04:00
James Godfrey-Kittle
d64a3c6619 Show build status in readme 2016-07-27 13:54:27 -07:00
James Godfrey-Kittle
0479616451 Merge pull request #34 from googlei18n/update-tests 
Add travis config file
 2016-07-27 13:50:59 -07:00
James Godfrey-Kittle
79beda96a4 Change expected test results for travis 
This is kind of annoying, because I don't get these results running
the test locally. Hoping it's a user error of some sort on my part.
 2016-07-27 13:48:19 -07:00