behdad

msdf still suffers from detail loss at large sizes, which this method doesn't have.

A wave of manic energy in December had me put together a long deck called "HarfBuzz at 20! " , celebrating 20 years of HarfBuzz.

I designed the deck to be presented at the #WebEnginesHackfest later this year. Then reality hit that I cannot present this deck in any sane amount of time.

I decided that instead of tossing the deck out, I just out to be read by the curious. I will present a highly condensed version at the hackfest in June.

Let me know what you think.

I have a puzzle for the hacker in you: The font HarfBust.ttf is an offshoot of Anton Regular, with a twist:

  - On software using HarfBuzz (as far back as you go, back to the 2000s) and HarfBuzz only, it will ligate "HarfBuzz" to the HarfBuzz logo.

  - On software using HarfRust and HarfRust only, it will ligate "HarfRust" to the HarfBuzz logo.

  - On software using HarfBuzz, HarfRust, or DirectWrite, but not CoreText, it will ligate "HarfBust" to the HarfBuzz logo.

Enjoy, --behdad

Thank you for the question. Rasterization is not my specialty. There definitely is still immense amount of research going into rasterizing fonts and 2D graphics on the GPU efficiently. Here's the latest from Raph Levien's research for example:

  https://www.youtube.com/watch?v=_sv8K190Zps

We’re the maintainers of HarfBuzz, the open-source text shaping engine used by browsers, operating systems, and applications to render all text, including supporting scripts like Arabic, Devanagari, Khmer, CJK, and more.

HarfBuzz is known for being fast, portable, and complete. But it’s also sometimes seen as hard to understand or work with. We’re working on a Developer FAQ and Design Notes to clear up misconceptions and explain the "why" behind our more unusual design decisions (yes, the macros are intentional).

So we’re asking:

What was your biggest WTF moment reading or using HarfBuzz?

Other things we’d love to hear about:

* Which parts felt like magic or a black box? * What do you think we could explain better? * Have you run into performance or integration surprises? * Are there features you only discovered by reading the source? * What do you wish the documentation had told you?

Anything else you want to know about the project?

We'll answer questions on Reddit, here, and also open a GitHub Discussion afterward to collect and respond to feedback more formally and integrate into our documentation.

Thanks in advance for your curiosity, stories, or frustration—we’re listening!

Browser zoom works fine for me. Does it not for you?

Hi. As mentioned, I'll expand on my motivations in a future paper. -behdad

Like it or not for hiring purposes it does.

How does that work with new grads?

Assuming that the dictionary is arbitrary as well, just comparing the string to the strings in the dictionary (or hashing it) it takes O(n), regardless of the data-structure you use.

That is a correct solution. The one I was talking about would stop after just trying "The" and "reis".

My bad. The dictionary should be {"the", "there", "is"}.

Imagine the string "there is", and the dictionary {"the", "there", "is"}.

I beg to differ, this is exactly the opposite of a manhole problem, which I tried to explain, which I clearly failed.

My mid-mark would be where someone could write the code for the brute-force answer for both parts but couldn't get the memoize / dynamic-programming solution. That would be where I'd say "I'm not sure, look at other interviews". Otherwise I'll make a hire / no-hire recommendation.

You'd be surprised.. but we're trying to distinguish between someone who can code simple algorithms versus one who can't.

Typically candidates are scored on a scale. And there are multiple interviews. The final hire / no-hire is decided based on the scores and written feedback from all interviews.

It is true that many companies, Google included, have added area-specific questions including some for frontend webdev if I remember correctly.

As someone who actually uses algorithms and data-structures in their job, I disagree.

Thanks. That's definitely an interesting question. How does it do with new grads? How do you grade people on that on a numerical scale? Curious.

This is very nice indeed. I should mock-interview someone using it.

How do you measure the question's success? Is there some kind of feedback you get about how the person you made a decision about went on to perform?

Not the latter. However, there are five interviews that each candidate goes through, and as an interviewer you get to read the interview feedback written by the other interviewers as well. So I can compare my assessment of a candidate against four other interviewers' assessment using their questions and feedback notes and rating assigned.

You are absolutely right. I should have been more clear about the dictionary size being large compared to n, and similar about the length of the longest word in it for all my analysis to follow.

Multiplication.

Thanks for the brick example. I'm going to use that a lot!

Consider the string "thereis", and the dictionary {"there", "is"}. The greedy algorithm fails.

I expect any candidate to be hired to be able to produce code for the brute-force cases, and do the runtime analysis on them.

It's a whole other debate that most software engineers, even at BigCo end up writing CSS code to move pixels only and lose their DSA knowledge over time...

Yes, the string equality itself is o(n).

n is the length of the string. As for why it matters whether it's linear or quadratic, we are assessing the candidates ability to analyze a problem and possibly improve an algorithm. It might not matter in the problem at hand.

That's the same as the trie solution.