Sketch out HTML support - #865
Merged
Merged
Conversation
We need a lot more infrastructure to allow proper HTML rendering.
This will be needed by the new spx2html engine that will be added shortly. It needs to use `XdvParser::process_with_seeks()` on its input file.
This is a new engine for creating HTML from TeX. SPX is "semantically paginated XDV", a slight variant on the XDV output created by the XeTeX engine during TeX processing. It looks like the it will be a misnomer: we're going to ignore the pagination of the XDV file. But whatever. We add a dependency on a patched version of "pinot", a crate for analyzing OpenType files. In order to deal with some math properly, we need to parse some of the special OpenType math tables. Also, update dependencies in Cargo.lock.
Codecov Report
@@ Coverage Diff @@
## master #865 +/- ##
==========================================
- Coverage 46.63% 46.02% -0.62%
==========================================
Files 146 147 +1
Lines 58983 59804 +821
==========================================
+ Hits 27508 27522 +14
- Misses 31475 32282 +807
Continue to review full report at Codecov.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I think that I've figured out the key technical pieces to deliver acceptable HTML support. The basic model is that we'll mainly output HTML, but emit special "canvas" sections when precise glyph positioning is needed, as in equations. The challenge in those places is not so much getting glyphs in the right positions — that's tedious but doable if you can control the CSS and examine the details of the active font — but getting the browser to display any desired glyph. Some glyphs are accessible as Unicode characters, which we can reverse-map from the font data, but others aren't.
Our key solution here is to emit new variant font files with customized character maps that deliver the glyphs that we need. This is basically a form of subsetting, although one not generally supported/envisioned by existing workflows.
We implement this all using pinot for font introspection. I need to use a patched version to add some support for the OpenType MATH table to be able to reverse-map certain glyphs to Unicode.
Various things here are labeled "tdux", which is an acronym for the Tectonic Default User Experience. This will be the name given to our standard HTML template and CSS conventions. I have no intention of trying to let people get totally freeform on the HTML/CSS side since I'm 99.9% sure there will inevitably have to be some pretty tight coupling between the TeX outputs and the HTML conversion to get consistently good output.
This code isn't super useful right now since I haven't yet created a repo with the work-in-progress TDUX HTML/CSS files. That will be coming along.