Hacker News new | ask | show | jobs
by vidarh 949 days ago
Similar thoughts on hinting - it's "good enough" for me on full HD w/just the antialiasing. With respect to automatic hinting, as I understand it Freetype has autohinting based on heuristics as hints in the fonts are often poor, but I haven't looked at how complex the auto hinter is.

Thanks for the nile and gezira link - it'd be fun to handle the emoji fonts too, at least as an addon...

Hammer looks interesting. I'm right in the middle of yet another parser combinator library in Ruby, but focused on text (it annoyed me that the Ruby Toml parser pulled in a 1500 line dependency for several hundreds of lines of excessively verbose parser definition for a grammar that can be defined in ca 50 lines) and frankly more an excuse to toy with refinements to see if I can get closer to BNF for specifying it.

I might have a look at hammer for inspiration for ways to shrink the ttf parser later.
1 comments
kragen 949 days ago
yeah, hammer is maybe small for a c parsing library but in absolute terms isn't that small (about 10 kloc if you leave out the bindings) but it might be good as a reference point for api design

because i'm not a fan of excessively verbose things, i've been tossing around ideas for a new non-parser-combinator-based peg parsing system called 'the monkey's paw' whose grammars look like this

    <expr: <first: <term: <digits: [0-9]+>              {parse_int(digits)}
                        | "(" \s* <expr> \s* ")"        {expr}
                        | <var: [A-Za-z_][A-Za-z_0-9]*> {read_var(var)}> {term}>
           \s* <rest: ( "+" \s* <term>  {term}
                      | "-" \s* <term>  {negate(term)}
                      )*>
           {add(first, sum(rest))}> {expr}
that's not really closer to bnf so maybe it's not what you're looking for, but my plan is to also support this syntax

    <expr> {expr}
    /where (
        <expr: <first> \s* <rest>            {add(first, sum(rest))}>
        <first: <term>                       {term}>
        <rest: ( "+" \s* <term>              {term}
               | "-" \s* <term>              {negate(term)}
               )*>
        <term: <digits: [0-9]+>              {parse_int(digits)}
             | "(" \s* <expr> \s* ")"        {expr}
             | <var: [A-Za-z_][A-Za-z_0-9]*> {read_var(var)}>
     )
which you can make even more bnf-like if you want by putting <digits> and <var> on their own lines

based on my experience with peg-bootstrap i suspect i can probably implement this metacircularly in about 100 lines of code in something like lua, js, or ruby, but getting it built in a non-self-referential way will take another 100 or so. i wasn't planning on doing hammer-style bitfields and stuff, and though i might end up with hammer-style parser combinators for bootstrapping, the idea is to use a host-language-independent grammar syntax as the main way to define grammars

link
vidarh 949 days ago
> that's not really closer to bnf so maybe it's not what you're looking for

I'm really toying with a variety of things. One thing is the smaller/cleaner parsing of binary formats.

The other thing I'm playing with is seeing how close I get to cleanly expressing the grammars in pure Ruby, without parsing an external format. The two things are pretty orthogonal, and always enjoy looking at new ideas for parsing in general, not just what I can abuse the Ruby parser to handle directly...

Your format is interesting. I read it as the <name: ...> bit serving as a capture? If were to map that to Ruby, I'd probably use the Hash syntax to try to approximate it, so you'd end up with something "{expr: {first: ...}". Incorporating the actions without some extra clutter would be a bit tricky, because the operator overload's won't let you add a block, and so you're stuck with a minimum of ->() {...} or lambda { ... }, but I think representing it reasonably cleanly would be possible (of course this looks like a simple enough format to just parse directly as well).

For a taste of how close to avoiding "host language noise" you can get when embedding the grammars directly in Ruby (I've not settled on the specific operators, but it's a bit limited since you can't change the precedence, I do think the '/' which came from ABNF might have been a poor choice and I might revert to '|' in particular), here's a small fragment of the Toml grammar that will parse as valid Ruby with the right code:

    toml               <= expression & 0*(newline & expression)
    expression         <=  ws & [keyval / table] & ws & [ comment ]
    ws                 <= 0*wschar
    wschar             <= 0x20 / 0x09
    newline            <= 0x0a / (0x0d & 0x0a)
But that so far excludes captures. I'm tempted to default to simply capturing the terms by name.

The trick to making the above valid Ruby that this is defined inside a class that "uses" a set of refinements[1] that lexically overrides methods on a number of core classes only within the grammar definition, and then it instance_eval's the grammar within an object where method_missing returns an object that acts as a reference to named rules, so each rule is basically just a series of chained method calls (hence the annoying '&' - I think it may be viable to get rid of it by keeping track of state in the object whose method_missing gets invoked, but I'm not sure if it'll be robust enough to be worth the slight reduction in visual clutter)

Without the refinement feature we'd have to wrap the integers etc. if we didn't want to monkey-patch the standard classes and break everything. (This kind of DSL is the only really useful case I've found for the refinements feature so far)

[1] https://docs.ruby-lang.org/en/master/syntax/refinements_rdoc...

link