polyfile
djot
polyfile | djot | |
---|---|---|
2 | 43 | |
323 | 1,580 | |
0.6% | - | |
7.6 | 5.8 | |
2 months ago | 2 months ago | |
Python | HTML | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
polyfile
- Blind Spots: Automatically detecting ignored program inputs
-
Show HN: I am building a new Python library to read/write PDF files
Be careful with PDF! There are many ambiguities in the specification that are implemented differently between parsers, as well as implicitly accepted malformations that almost all parsers will silently accept without warning. It is very easy to accidentally produce so-called file format schizophrenia: When the same file is rendered differently between two parsers. For example, with PDF, what if you have a PDF object stream that has a length that doesn't agree with the position of its `endstream` token? What if you have a PDF dictionary with duplicate keys? Do you use the value of the first key or the second? What if you have two, valid PDFs concatenated one after the other? Do you render the first or the second? What if an object in the XREF table has an incorrect offset?
Shameless plug: I am one of the maintainers of PolyFile, which, among other things, can produce an interactive HTML hex editor with an annotated syntax tree for dozens of filetypes, including PDF. For PDF, it uses a dynamically instrumented version of the PDFminer parser. It sounds like it might satisfy your use case.
https://github.com/trailofbits/polyfile
djot
-
LaTeX and Neovim for technical note-taking
I know this doesn't solve your problem directly, but I recommend people to try out Djot[0], a markup language from the author of CommonMark.
Djot has a single well-defined spec, and most of the basic formatting has the same syntax as (a) Markdown, so switching is pretty painless. It has as a main goal to be legible and visually aesthetic as-is, just like Markdown.
What Djot adds is its _predictability_. Nested formatting, precedence order, line breaks behavior, nested blocks, mixed inline and block formatting, custom attributes are all laid out precisely in the spec in a thought-out manner. Till this day I still can't remember how to put line break within a list item in Markdown (and I'm sure there're more than one way).
[0]: https://djot.net/
- Pandoc 3.1.12 Released
-
Pandoc
Worth noting that the author has also created a markup language, djot.
https://github.com/jgm/djot
-
Augmenting the Markdown Language for Great Python Graphical Interfaces
Every time I see people doing something with Markdown, I wish they just replace it with support for Djot[0] instead. It is a Markdown alternative by the creator of Pandoc and CommonMark that fixes all of the most egregious mistakes, while being legible and visually pleasant as-is. It is also syntactically similar to Markdown, which should ease adoption.
[0] https://github.com/jgm/djot
- Djot is a light markup syntax
- Beyond Markdown
-
HELP!!! Stuck forever
Are you using markdown? It might make sense to look at 'djot' as well: https://djot.net/; it's a new 'light' markup language conceived as a successor to commonmark; development is led by none other than John McFarlane (author of pandoc, & also led commonmark standardization) Djot makes it really easy to attach arbitrary attributes to block elements as well as inline elements; and the parser records source positions in the output -- all of which makes it really convenient keeping track of elements changing position or value.
-
Is there a way to send data from neovim in real-time to other applications? Want to create a neovim qmk bridge.
I have a simple script that sends a djot buffer (https://github.com/jgm/djot) to the parser, if there's a change, on the CursorHold event.
-
wiki.vim v0.6 is released
Since you mentioned you were considering moving to CommonMark, have you had time to look into Djot (also by jpm)? Djot is meant to be easier to parse, and I'm planning to write a tree-sitter grammar for it.
-
Typst, a modern LaTeX alternative written in Rust, is now open source
Another recent development here is https://djot.net/ (by the pandoc author). It indeed thoroughly solves both:
What are some alternatives?
PyMuPDF - PyMuPDF is a high performance Python library for data extraction, analysis, conversion & manipulation of PDF (and other) documents.
typst - A new markup-based typesetting system that is powerful and easy to learn.
polytracker - An LLVM-based instrumentation tool for universal taint tracking, dataflow analysis, and tracing.
mdBook - Create book from markdown files. Like Gitbook but implemented in Rust
pdfquery - A fast and friendly PDF scraping library.
Zato - ESB, SOA, REST, APIs and Cloud Integrations in Python
pdfplumber - Plumb a PDF for detailed information about each char, rectangle, line, et cetera — and easily extract text and tables.
scroll - Tools for thought. An extensible alternative to Markdown.
pdfsyntax - A Python library to inspect and modify the internal structure of a PDF file
mupdf - mirrored from git://git.ghostscript.com/mupdf.git