Khaled Hosny

@JosephWright github.com/latex3/luaotfload/issues/300

@JosephWright I guess then asking on luaotfload issue tracker is where one gets a definitive answer as David suggested above.

@JosephWright I was not aware that matching ConTeXt behavior is a concern, but if it is then that is one answer to my question.

@JosephWright That is why I’m asking. I’m aware of the inadequate handling of hyphenation, but I’m not aware of other issue with these scripts.

@DavidCarlisle Makes sense, thanks

Also, would there be any interest in allowing harf mode for math fonts? HarfBuzz would be used only to load the font and get data from the MATH table, but math typesetting would still be done by the engine as usual. I’m hoping using harf mode would allow me to avoid issues like github.com/latex3/luaotfload/issues/278

Hi, a quick question. I’d like to see HarfBuzz the default in luaotfload, is there a possibility of this ever happening. Lets say I have a time to work on the hyphenation issue (I don’t currently) and I mange to get it in an acceptable state, would there be any other blockers to making harf mode the default?

@DavidCarlisle I don’t know any implementation that support this. May be it is possible at some current implementations, but I never tried it. My recollection is that implementations either grow glyphs vertically (anything bug accents) or horizontally (accents)

@DavidCarlisle It is a bit complicated. HarfBuzz, DirectWrite, etc, will set the advance width of mark glyphs to zero regardless of the advance set in the font (and many fonts depend on that), but not for all scripts. For some Indic scripts the width of marks is respected (though, I don’t remember which ones, and the node shaper might not support them anyway).

@DavidCarlisle Some people want \sum to stretch horizontally, so a font designed this way would have it grow vertically (for display size) as well as horizontally.

@DavidCarlisle There is a PR github.com/latex3/luaotfload/pull/299 and it looks like it comes from ConTeXt code

I think someone might be interested in this thread forum.glyphsapp.com/t/…

@mickep I mean, it shows that my interpretation matches the implementation. The font data might be less than ideal, but that is then a font issue to fix.

@mickep Here is another font with both vertical and horizontal gaps set to 0

@mickep MS Office seems to render it with a +ve vertical gap

@mickep I’m away from my computer now, but I’ll check it later

@mickep The skewedFractionVerticalGap text was basically based on “reverse engineering” what MS implementation does, but probably not many fonts were tested against it.

@mickep Nagwa TK is a companion for Adobe’s Tekton font, based on a Type1 TeX font that Nagwa acquired the rights for (I don't remember from which defunct TeX company), but the Arabic part is brand new.

@mickep Yes, I did the MATH table engineering for IBM Plex Math and some general math fonts consultation

I hope it will help more people build more math fonts. It fiscusses some topic that is not discussed elsewhere AFAIK, like how to choose sensible value for the various math constants.

I wrote also an article on math font development for Noto project, github.com/notofonts/math/blob/main/documentation/…

@mickep Fonts is such a wide area, but I have been doing some work on math fonts lately (Noto Sans Math, IBM Plex Math, and Nagwa TK Math), thought that is probably old news.

@mickep hi

@PauloCereda LibreOffice seems to use either -O2 or -Os, but it wasn't passing it to HarfBuzz build initially

@FaheemMitha It does, opening a medium size document it LibreOffice typically calls HarfBuzz a millions (or may be billions, it was a while since I last measured this) times. Just asking the compiler to optimize HarfBuzz gave measurable performance difference.

@FaheemMitha For software included in TeX Live, yes.

@PauloCereda Because you built them yourself, now go tell him he needs a java compiler now :)

@DavidCarlisle Fortran and new "systems programming" languages like Rust provide C API for this very reason.

I wouldn't want to the person to tell Karl some software in TeX Live needs Rust/Haskel/Lisp compiler, he was very upset when HarfBuzz stopped building with gcc 4.8.

@DavidCarlisle Also since C API seems to be the API exposed by all systems in use today, any low level library needs to expose a C API to be usable by higher level ones.

@FaheemMitha that is the only question, you pick the language good for the job, not the language then the job

@DavidCarlisle That is neither a TeX engine nor included in TeX Live :)

@DavidCarlisle you missed luahbjittex

@FaheemMitha There are, but which would be suitable for a library like HarfBuzz?

@JosephWright I see.

@DavidCarlisle I don't know what to do either.

@DavidCarlisle (that would be 6 if we count "lmtx", so that one is probably not "subtly different).

@DavidCarlisle Whatever puts food on the table

@HaraldHanche-Olsen You should include line number in the name too :)

I'm really confused by the latest LuaTeX development and not sure what should I do. We certainly don't want 5 subtly different LuaTeX engines in TeX Live, right?

@DavidCarlisle Do you write Fortran? you would be the second person I know who does Fortran.

@JosephWright Of course, silly me :)

@FaheemMitha What else should people use, C?

@UlrikeFischer Now that is problem, I'm implmenting these ligatures really as TeX ligatures, so they behave like base mode ligatures and I have no much control over that (and \char"7d- with TFM Computer Modern does produce an em dash as well, so node mode is the outlier here).

@UlrikeFischer Another difference between base and node, \char"2013- will produce em dash in base mode, but en dash followed by hyphen in node mode.

@UlrikeFischer I wouldn't mind either, but Computer Modern have them, so why not (it doesn't have ,, <<>> though, and these I'd be more happy to remove, but IIRC the XeTeX mapping file has them)

@UlrikeFischer cleaning up and will commit soon. Notice the last line (that is base mode) there are two quotes not a double one

@UlrikeFischer ^