Здравствуйте, Pzz, Вы писали:
vsb>>1. LaTeX даёт красивый результат с хорошей поддержкой математических формул с абсолютно минимальными усилиями для типичной научной статьи. Можешь попробовать написать что-нибудь подобное, но не факт, что у тебя получится.
Pzz>Мне, кстати, современное издание Кнута, типографически очень похожее на оригинальное англоязычное издание, которое, как известно, сверстано техом, нравится куда как менее, чем старое советское издание, сверстанное более традиционными методами. Чисто со зрительной точки зрения.
Ну если уметь верстать, можно и без него. Речь о человеке, который пишет статью или малобюджетную книгу, не являясь специалистом по типографике. Банально: переносы сделать грамотно. Из того, что я видел: только TeX умеет проверять, приемлемо ли переноситься заданный текст при выравнивании по обеим сторонам. Остальные ничтоже сумняшеся растягивают пробелы как угодно, получая некрасивые строчки. А так если денег хватает нанять специалистов, понятно, что и без него верстают, может быть и лучше.
vsb>>3. Основной конкурент LaTeX-у это Microsoft Word.
Pzz>По-моему, это совершенно разные продукты для совершенно разных людей.
На самом деле нет. И в научных конференциях и журналах принимают оба формата и для дипломов и курсовых используют оба формата чаще всего. У LaTeX достаточно высокий порог вхождения, тогда как Word можно запустить и писать, в том числе формулы и результат будет приемлемым и по виду и по скорости. Поэтому кто-то заморачивается и выучивает его, кто-то нет.
Здравствуйте, night beast, Вы писали:
NB>возможность написать непосредственно букву в техе есть. NB>если клава поддерживает, пользуйся.
Можно вообще заказать написание на аутсорс, тогда и поддержка клавой не нужна, пользуйся. Но это не решение проблемы, а перекладывание ее на чужие плечи. Впрочем, чего еще ожидать от лялих-вэя?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Pzz, Вы писали:
Pzz>Расстояния он считает, скорее всего, в той системе, которая принята в типографии. Что и разумно: на выходе теха, в идеале, получается пригодная к печати книжка или журнальная статья.
В типографиях уже лет 20 привязка к реальным размерам осталась только как ориентир, все что не выходит за рамки возможностей железа, сделают с высокой точностью в любых единицах.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, klopodav, Вы писали:
K>А как именно работать с представлением? Для того, для чего используют TeX — что-то еще не придумали никакого способа работы с представлением, чтобы это было в среднем удобнее и эффективнее набора текста с командами.
А не очень-то и старались.
K>Например, для программирования тоже придумывали множество систем, чтобы писать программы перетаскиванием блоков и стрелочек. Но в основной массе это не взлетело — неудобно (а для похожей смежной задачи, если нужно не программирование, а моделирование — вполне себе взлетает).
Для программирования есть очень много чего: в двоичном коде не пишет никто, на ассемблере очень мало, а сам код, манипулирующий абстракциями, скрывающими многие тысячи примитивных команд, раскрашивается, форматируется и дополняется на лету, без всякой дополнительной метаинформации. И на каждом этапе той эволюции были нытики, кричавшие, что ассемблер эффективнее.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vsb, Вы писали: vsb>>>3. Основной конкурент LaTeX-у это Microsoft Word. Pzz>>По-моему, это совершенно разные продукты для совершенно разных людей. vsb>На самом деле нет. И в научных конференциях и журналах принимают оба формата и для дипломов и курсовых используют оба формата чаще всего. У LaTeX достаточно высокий порог вхождения, тогда как Word можно запустить и писать, в том числе формулы и результат будет приемлемым и по виду и по скорости. Поэтому кто-то заморачивается и выучивает его, кто-то нет.
K>>Например, для программирования тоже придумывали множество систем, чтобы писать программы перетаскиванием блоков и стрелочек. Но в основной массе это не взлетело — неудобно (а для похожей смежной задачи, если нужно не программирование, а моделирование — вполне себе взлетает).
Ops>Для программирования есть очень много чего: в двоичном коде не пишет никто, на ассемблере очень мало, а сам код, манипулирующий абстракциями, скрывающими многие тысячи примитивных команд, раскрашивается, форматируется и дополняется на лету, без всякой дополнительной метаинформации.
Так для TeXа есть примерно все то же самое — и наборы из многих прмитивных команд можно завернуть в свою абстракцию, и подсветку синтаксиса в редакторах можно включить. Более того — редакторы кода из многие из обычных IDE можно в принципе настроить на редактирование ТеХа (я на практике таким не пользовался, но теоретически можно).
Здравствуйте, klopodav, Вы писали:
K>Так для TeXа есть примерно все то же самое — и наборы из многих прмитивных команд можно завернуть в свою абстракцию
Так в том-то и дело, что для программирования у меня уже есть различные готовые API, библиотеки и фреймворки. Оно уже завернуто в абстракции, мне не надо выдумывать их самому в 99% случаев. Я даже циклы почти не пишу, а беру готовые алгоритмы, имеющие определенные гарантии и минимум багов в реализации.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
K>>Так для TeXа есть примерно все то же самое — и наборы из многих прмитивных команд можно завернуть в свою абстракцию
Ops>Так в том-то и дело, что для программирования у меня уже есть различные готовые API, библиотеки и фреймворки. Оно уже завернуто в абстракции, мне не надо выдумывать их самому в 99% случаев. Я даже циклы почти не пишу, а беру готовые алгоритмы, имеющие определенные гарантии и минимум багов в реализации.
не хотел тебя разочаровывать, но в техе все так-же.
латех по сути и является одной из таких библиотек, точнее даже, набор библиотек.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>С тех пор уже придумали XML, семантическую разметку, json наконец.
Ни XML,ни JSON не определяют семантику (т.е. "значение" конкретных полей). Она определяется поверх (т.е. отдельно). Здесь принципиальной разницы для писателей (и читателей исходника) нет. Разница есть при изначальной разработке парсера. Для json и xml можно взять готовый "лексический анализатор". Но в TeX подобные парсеры уже есть. Что мы выиграем при замене формата.
ЭФ>Ведь ничего сложного в том, чтобы написать программу, которая формирует .pdf-файл ЭФ>из XML-файла, а последний можно редактировать в любом текстовом редакторе ЭФ>так же как и .tex-файлы.
Можно, конечно. Но зачем, если такая программа уже есть. В чем преимущество? Если вам хочется странного, можно взять TeXML (для определенных областей вроде машинной генерации текста — самое удачное решение).
Более того, TeX — это не только язык разметки. Это еще и специализированный язык программирования. Именно макросы позволяют добавлять новые понятия (семантические единицы). Макросы же позволяют изменять стиль отображения. Какие из почти шести тысяч пакетов, предоставляемых https://www.ctan.org/, вы включите в вашу программу? Там есть и сложная функциональность, включая вызов внешних программ. Например, форматирование и раскраска исходного кода делаятся через вызов питновского pygments. А в техе такой код — всего лишь специфическое окружение (environment).
Да и зачем вам вообще XML? Почему бы не взять библиотеку и не написать программу, генерирующую сразу нужный выходной PDF? Зачем вам какие-то полумеры в виде XML? Код программы-генератора можно редактировать в любом текстовом редакторе, так же, как и .xml-файлы. Если что — я не прикалываюсь. С какого-то момента вместо изобретения очередного языка может быть гораздо выгоднее просто взять библиотеку (или там конкретную реализацию абстрактного API) чем постоянно дописывать "макроязык" под незапланированные хотелки.
ЭФ>Что такого есть в этом LaTeX, раз его ещё до сих пор не переписали на rust и json ?
А что даст переписывание входного формата? Да ничего. Там, где возможностей не хватает — пишут другие модули и процессоры. Тот же XeTeX, например, для нормальной поддержки Unicode и генерации PDF напрямую. В общем, проблем с форматом исходного .tex ни у кого нет, так зачем что-то менять?
ЭФ>Вот что вы смеётесь? В WPF описывается изображение при помощи XML, а представляете, если бы там были TeX макросы?
А давайте я вам пошлю фотку и вы ее "при помощи XML" опишите? Без прибегания к читам вроде "а вот здесь у нас лежит jpeg blob". Если хотите попроще — есть https://ctan.org/pkg/forest Посмотрите его примеры и попробуйте нарисовать в WPF. В tex пакет делает много верстки, включая определение размеров прямоугольников, уровни дерева, линии и т.п. В WPF тоже все автоматически будет, или нужно будет каждый узел вручную по-координатам расписывать (и при смене шрифта заново все вычислять)?
Отлично, вставка .svg в нём есть, через векторную графику можно запихнуть любые формулы.
Equations can be edited in the Oxygen built-in MathML editor.
...
The MathML equations included in DocBook documents are rendered in the PDF and XHTML output of the DocBook transformations.
...
Styled content can be inserted by copying content from Office applications (Microsoft Word, Microsoft Excel, OpenOffice.org Writer, OpenOffice.org Calc) and Web browsers (Mozilla Firefox, Microsoft Internet Explorer, Google Chrome), and pasting it in the DocBook editor.
Остался только вопрос — а где же текстовые процессоры, которые DocBook редактируют?
Many graphical or WYSIWYG XML editors come with the ability to edit DocBook like a word processor.[citation needed]
NB>>>как будет выглядеть в xml что-то вида $\int_a^b \frac {dx}{\(\dot x + 1\)^2} $? ЭФ>>переводил онлайн переводчиком: K>А теперь для эксперимента набери с клавиатуры первое и второе
Задание со звездочкой: после набора, закоммить в гит, затем немного поменяй формулу, закоммить изменения, посмотри дифф и попытайся понять что произошло.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Что такого есть в этом LaTeX, раз его ещё до сих пор не переписали на rust и json ?
И еще один момент. А зачем его переписывать на rust и json? Ведь после того, как придумали XML и семантическую разметку, придумали еще и XSLT — специальный XML для переливания из пустого в порожнее конвертации семантических данных в их представление. XSLT-процессоры есть на любой вкус. Поэтому достаточно написать "простенький XSLT-stylesheet" для конвертации семантического XML сразу в PDF и ничего придумывать не надо. Или это плохая идея по каким-то причиниам . Если хочется экспериментировать — можете взять какой-нибудь исходник (ну например, введение в tex — https://ctan.org/pkg/lshort-russian) и сделать его в XML-формате вместо tex. Плюс написать XSLT. Для прототипа PDF, наверное, не нужно, можно конвертировать XML в TeX. А прямое XML->PDF преобразование будет сделать уже в версии 1.0.
Здравствуйте, maxkar, Вы писали:
ЭФ>>Что такого есть в этом LaTeX, раз его ещё до сих пор не переписали на rust и json ?
M>И еще один момент. А зачем его переписывать на rust и json? Ведь после того, как придумали XML и семантическую разметку, придумали еще и XSLT — специальный XML для переливания из пустого в порожнее конвертации семантических данных в их представление. XSLT-процессоры есть на любой вкус.
вопрос немного в сторону.
его XSLT где-то в промышленных масштабах используют?
был небольшой опыт с генерацией, впечатления остались не очень положительные (задачу сделал, но на чем то другом получилось бы и быстрее и понятнее)
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>>Что такого есть в этом LaTeX, раз его ещё до сих пор не переписали на rust и json ?
M>И еще один момент. А зачем его переписывать на rust и json? Ведь после того, как придумали XML и семантическую разметку, придумали еще и XSLT — специальный XML для переливания из пустого в порожнее конвертации семантических данных в их представление. XSLT-процессоры есть на любой вкус. Поэтому достаточно написать "простенький XSLT-stylesheet" для конвертации семантического XML сразу в PDF и ничего придумывать не надо. Или это плохая идея по каким-то причиниам . Если хочется экспериментировать — можете взять какой-нибудь исходник (ну например, введение в tex — https://ctan.org/pkg/lshort-russian) и сделать его в XML-формате вместо tex. Плюс написать XSLT. Для прототипа PDF, наверное, не нужно, можно конвертировать XML в TeX. А прямое XML->PDF преобразование будет сделать уже в версии 1.0.
Я кстати имел такой опыт. Какая же это хрень. исходный документ в DocBook (xml)
нужно было выдать в pdf оформленном по ГОСТ. Сначала пару дней "трахался" с https://xmlgraphics.apache.org/fop/ ,
шрифты ведь нужно в pdf описывать, еще какие-то баги в Java коде вообщем было весело.
Потом написание "декоратора" чтобы полученный документ был по ГОСТу,
по-моему пару недель заняло из-за чудесной огромной кодовой базы XSLT скриптов в DocBook
и багов fop. В общем-то я скорее всего за тот же промежуток времени смог бы
все это перевести TeX и сгенерировать нужный pdf по ГОСТу, но мы все сильны задним умом,
а на старте была трендовая тогда технология XML и куча обещаний как она упростит вашу жизнь.
Здравствуйте, velkin, Вы писали:
ЭФ>>Ведь ничего сложного в том, чтобы написать программу, которая формирует .pdf-файл ЭФ>>из XML-файла ЭФ>>Что такого есть в этом LaTeX, раз его ещё до сих пор не переписали на rust и json ?
V>Многие отказываются от latex в пользу более простых систем документирования, так сказать ближе к людям. Что касается вопроса, для примера, есть DocBook и многие другие.
Здравствуйте, Ops, Вы писали:
K>>Так для TeXа есть примерно все то же самое — и наборы из многих прмитивных команд можно завернуть в свою абстракцию
Ops>Так в том-то и дело, что для программирования у меня уже есть различные готовые API, библиотеки и фреймворки. Оно уже завернуто в абстракции, мне не надо выдумывать их самому в 99% случаев. Я даже циклы почти не пишу, а беру готовые алгоритмы, имеющие определенные гарантии и минимум багов в реализации.
Так и в ТеХе на самом деле все нормально завернуто. Но если у тебя есть часто повторяющиеся последовательности, то ты их можешь легко и непринуждённо завернуть в свою еще более высокоуровневую команду
С ним проблема только в том, что TeX — это база, а вот то, чем можно пользоваться — высокоуровневые пакеты типа LaTeX и тп — на линупсе еще вроде худо бедно работало, а под винду кучи кучи разных портов разной степени кривизны, и везде гавнецо какое-то вылазит, какой-то доп пакет прикрутить — постоянно приседать надо, с кодировками опять же гемор и тд и тп, не умело нормальный rtf/word генерить, мне тогда еще справка виндовая нужна была. Это лет 20 уж назад было, может сейчас лучше. Но я уже старый и ленивый, снова ковыряться лень, да и давно уже пользуюсь самописной системой, которую кстати когда писал, поглядывал на TeX
Здравствуйте, maxkar, Вы писали:
ЭФ>>Что такого есть в этом LaTeX, раз его ещё до сих пор не переписали на rust и json ?
M>И еще один момент. А зачем его переписывать на rust и json? Ведь после того, как придумали XML и семантическую разметку, придумали еще и XSLT — специальный XML для переливания из пустого в порожнее конвертации семантических данных в их представление. XSLT-процессоры есть на любой вкус. Поэтому достаточно написать "простенький XSLT-stylesheet" для конвертации семантического XML сразу в PDF и ничего придумывать не надо. Или это плохая идея по каким-то причиниам .
. Если хочется экспериментировать — можете взять какой-нибудь исходник (ну например, введение в tex — https://ctan.org/pkg/lshort-russian) и сделать его в XML-формате вместо tex. Плюс написать XSLT. Для прототипа PDF, наверное, не нужно, можно конвертировать XML в TeX. А прямое XML->PDF преобразование будет сделать уже в версии 1.0.
