Комментарии 8
Хотя бы тесты можно было привести: какой способ для каких документов лучше.
Так лучше? Просто так сложно ответить, все равно придется собственные тесты смотреть.
Картинки с примерами не отображаются.
А ещё было бы здорово провести тесты по скорости и выложить результаты.
Ох… По-моему, начинать стоило с конца — что была такая прикольная задача конвертить TeX в MathML — и вот получился такой свободный проект. Использовать ли его «программисту .NET» или кому-то еще — на самом деле абсолютно вторично, Ваш проект-то достаточно универсален, чтобы его встраивать чуть ли не в сайты на PHP.
Самое интересное — что бы хотелось увидеть — зачем понадобилось писать n+1-ый конвертер latex→mathml — какое-то сравнение с существующими аналогами и указание, где они плохи. Я уверен, что Вы наверняка перепробовали их массу и они все чем-то не понравились — было бы очень интересно узнать чем именно.
Самое интересное — что бы хотелось увидеть — зачем понадобилось писать n+1-ый конвертер latex→mathml — какое-то сравнение с существующими аналогами и указание, где они плохи. Я уверен, что Вы наверняка перепробовали их массу и они все чем-то не понравились — было бы очень интересно узнать чем именно.
Интересно, что Ваш любимый (что с очевидностью вытекает из приведённого обзора) способ решения обозначенной проблемы (я имею в виду написанный Вами же конвертер LaTeX -> MathML) демонстрирует очень и очень плохие результаты, если судить по приведённым Вами же тестам.
Судите сами: если документ объёмом в 1 Кб рендерится 3 секунды, а документ 8.5 Кб рендерится уже 12 (ого!) секунд, значит, если принять сложность алгоритма равной O(N), документ объёмом 100 Кб будет рендериться с использованием Вашего движка уже больше минуты.
Из этих же тестов видно, что старый добрый pdflatex демонстрирует куда большую масштабируемость по объёму генерируемого документа, обеспечивая скорость рендеринга, на порядок превосходящую LaTeX -> MathML.
Судите сами: если документ объёмом в 1 Кб рендерится 3 секунды, а документ 8.5 Кб рендерится уже 12 (ого!) секунд, значит, если принять сложность алгоритма равной O(N), документ объёмом 100 Кб будет рендериться с использованием Вашего движка уже больше минуты.
Из этих же тестов видно, что старый добрый pdflatex демонстрирует куда большую масштабируемость по объёму генерируемого документа, обеспечивая скорость рендеринга, на порядок превосходящую LaTeX -> MathML.
Любимый-не любимый, LaTeX -> MathML способ годится лишь для узкого круга задач с маленькими объемами документов. С этим не поспорить — дело в фиговой реализации рендеринга у Gecko (конвертер не при чем, ему что 5кб, что 100кб). Если уж начал писать велосипед, то по-видимому придется в будущем писать и рендеринг.
Что касается конвертера — нужен был тот, который бы без швов работал с C# кодом и мог бы легко изменяться под мои нужды. Конечно, если бы существовал portable (т.е. не tex4ht) конвертер с открытым кодом, демонстрирующий удовлетворительные результаты, я бы плюнул на бесшовность и использовал его. Увы, я 2 года искал такое решение и так и не нашел.
Что касается конвертера — нужен был тот, который бы без швов работал с C# кодом и мог бы легко изменяться под мои нужды. Конечно, если бы существовал portable (т.е. не tex4ht) конвертер с открытым кодом, демонстрирующий удовлетворительные результаты, я бы плюнул на бесшовность и использовал его. Увы, я 2 года искал такое решение и так и не нашел.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программисту .NET: как быстро показать LaTeX