Timo Rothenpieler (12020-08-21): > That seems long overdue to me. > The current approach to documentation has become very hard to properly > maintain.
This seems to get some approval.
I think it would probably not be very hard to convert existing
components in bulk.
I'll see if I can wrangle some perl.
> Something like Markdown would come to mind. It should have all formatting
> tools one needs for documentation.
There seem to be unanimity for Markdown, which is an excellent choice
too.
Markdown does not seem to have built-in syntax for @var{} / <var> or
@samp{} / <samp> or @opt{}, but this small loss of precision is probably
acceptable, or we can consider using inline HTML. To be decided later.
> Not really any strong opinion there. It'd increase the size of the binaries,
> but if its compressed not by a whole lot, and I can see it being useful
> specially for CLI users.
I do not think compression would be a good idea. It would reside mostly
in the .rodata section of the binary, using up space on disk which
almost nobody worries about, and being loaded into memory only on
demand. Compression would be more complex, and could end up costing more
memory in practice. But again, to be decided later.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
