make всё таки общеизвестная система, не привязанная к коннкретному языку
идея была как раз в том, чтобы показать аргументы командной строки
Аргументы, передаваемые в javac и т.п. в Makefile и так будут в явном виде. А вот аргументы вашего скрипта и код типа if "%1"=="build" - это скорее лишняя сущность, отвлекающая от сути. Но если предполагается, что кто-то из читателей не знаком с make - может, проще и на cmd...
Я не понимаю, почему автор make не запользовал - достаточно низкоуровнево, чтобы показать какими командами реально собирается проект, но без необходимости вручную анализировать аргументы командной строки и т.п.
Маяковский любил выражать информацию такими средствами. Так что теперь, его стихи запрещать? )
Мы всё таки о документах, из которых имеет смысл извлекать информацию в автоматизированном режиме.
А жесткие и простые методы ограничений использования макропакетов в TeX имеются.
Это уже не просто TeX, а TeX с жёсткими ограничениями. Если ещё добавить машинно читаемое описание структуры элементов в шаблоне и автоматическую проверку соответствия документа структуре - по сути будет тот же XML с другим синтаксисом )
В JSON или YAML таких проблем уже не возникает.
Это уже детали маппинга формата на текстовое представление. Мой основной момент в преимуществе декларативного описания над императивным.
XML встречается только в легаси.
Не очень понял, о чём речь. Мы же о документах, а не о коде.
автор точно знает, что после типографии он увидит свой труд в ожидаемом им виде
С точки зрения качества картинки - хорошо, с точки зрения автоматизированной обработки - плохо, потому что автор может явно или неявно выражать информацию чисто типографскими средствами.
журналы и издательства запрещают подключать пакеты
Я говорю о TeX как о формате и системе в целом, а не о практике использования в конкрентных местах. С хорошими coding guidelines и C++ - вполне читаемый язык )
При просмотре XML в Pull Request
Значит, нужны средства, вычисляющие и показывающие разницу на уровне xml элементов, а не plain text, который их выражает. Ну и редактировать по хорошему надо в среде, которая понимает DTD и даёт возможность создавать только корректный документ.
А docbook наоборот, рендерит так, как удобно читателю
Для печати и просмотра людьми docbook обычно рендерится в PDF на стороне автора или издательства.
И много Вы видели TeX шаблонов в стандартной поставке или от приличных журналов/издательств, где этой семантики нет?
Проблемы не с этими шаблонами, а с зоопарком пакетов на CTAN.
открываю, например, стандартный шаблон letter и вижу: \address, \letter, \signature, \opening, \telephone, \location и т.п
Если используются только чётко документированные параметры шаблона - нет проблем. Но TeX это никак не энфорсит - для валидности достаточно, если все макросы нормально раскроются и в результате получится валидный код для собственно TeX'овского движка. В xml можно как минимум проверить, что документ соответствует DTD.
Я не спорю с тем, что TeX хороший инструмент для написания научных статей или книг - но это не лучший формат для автоматизированной обработки.
Насколько помню, в меню игрушек выбирали Кемпстон, джойстик точно был самопальный с выструганной из деревяшки ручкой. Но может уже плохо помню, тем более что своего компьютера не было.
В него, скажем, FrameMaker умеет, вполне себе профессиональный инструмент.
иным путем обеспечить автоматическую верстку типографского качества вряд ли реально
Надо как то чётко разделять семантическую и типографскую разметку, в ТеXе оно переплетено. В xml-based форматах "типография" вынесена отдельно в stylesheet'ы.
чем в распознавании семантики этой фразы
Мы скорее о семантике структуры (вот этот текст - адрес, вот тот - цитата и т.д.), сам текст пускай LLM распознаёт )
В Commodore 64 из коробки обычный построчный Бейсик. Наверное, был сторонний софт с "обычным" редактированием текста - всё-таки у него даже дисковод был - но он же появился после того, как железку задизайнили.
make всё таки общеизвестная система, не привязанная к коннкретному языку
Аргументы, передаваемые в javac и т.п. в Makefile и так будут в явном виде. А вот аргументы вашего скрипта и код типа if "%1"=="build" - это скорее лишняя сущность, отвлекающая от сути. Но если предполагается, что кто-то из читателей не знаком с make - может, проще и на cmd...
Я не понимаю, почему автор make не запользовал - достаточно низкоуровнево, чтобы показать какими командами реально собирается проект, но без необходимости вручную анализировать аргументы командной строки и т.п.
Ну тогда sudo snap install chromium
Конечно будет, полуось и Fleetstreet наше всё )
Нижегородского
Там мог и округлить. Надо всё таки технические спецификации смотреть.
На мой взгляд всё-таки есть некое противоречие между физическим и логическим описанием, в разных случаях применимо разное.
Смотрю на банальный article.cls и сходу не вижу, где там требование иерархии вложенности part/section/subsection/...
Это всё таки специфическая деятельность, я большее о массовой обработке больших документов.
Где то в 93ем первый раз и видел/слышал Covox. Но уже в 96ом прикупил за недорого SBPro-compatible карточку на ESS688.
Мы всё таки о документах, из которых имеет смысл извлекать информацию в автоматизированном режиме.
Это уже не просто TeX, а TeX с жёсткими ограничениями. Если ещё добавить машинно читаемое описание структуры элементов в шаблоне и автоматическую проверку соответствия документа структуре - по сути будет тот же XML с другим синтаксисом )
Это уже детали маппинга формата на текстовое представление. Мой основной момент в преимуществе декларативного описания над императивным.
Не очень понял, о чём речь. Мы же о документах, а не о коде.
Разве не 22050 Гц?
С точки зрения качества картинки - хорошо, с точки зрения автоматизированной обработки - плохо, потому что автор может явно или неявно выражать информацию чисто типографскими средствами.
Я говорю о TeX как о формате и системе в целом, а не о практике использования в конкрентных местах. С хорошими coding guidelines и C++ - вполне читаемый язык )
Значит, нужны средства, вычисляющие и показывающие разницу на уровне xml элементов, а не plain text, который их выражает. Ну и редактировать по хорошему надо в среде, которая понимает DTD и даёт возможность создавать только корректный документ.
Для печати и просмотра людьми docbook обычно рендерится в PDF на стороне автора или издательства.
Проблемы не с этими шаблонами, а с зоопарком пакетов на CTAN.
Если используются только чётко документированные параметры шаблона - нет проблем. Но TeX это никак не энфорсит - для валидности достаточно, если все макросы нормально раскроются и в результате получится валидный код для собственно TeX'овского движка. В xml можно как минимум проверить, что документ соответствует DTD.
Я не спорю с тем, что TeX хороший инструмент для написания научных статей или книг - но это не лучший формат для автоматизированной обработки.
Нет, обычные PC compatible с виндой.
Каком стандартном, у нас на работе таких больших не выдают) Правда, в офисе всё таки можно подключить полноценные клавиатуру/монитор.
Часто просто отсутствует, по крайней мере на 14" и меньше.
Насколько помню, в меню игрушек выбирали Кемпстон, джойстик точно был самопальный с выструганной из деревяшки ручкой. Но может уже плохо помню, тем более что своего компьютера не было.
В него, скажем, FrameMaker умеет, вполне себе профессиональный инструмент.
Надо как то чётко разделять семантическую и типографскую разметку, в ТеXе оно переплетено. В xml-based форматах "типография" вынесена отдельно в stylesheet'ы.
Мы скорее о семантике структуры (вот этот текст - адрес, вот тот - цитата и т.д.), сам текст пускай LLM распознаёт )
Что это? По дальнейшему тексту речь о коде ядра, обновляющем микрокод процессора.
Я скорее с docbook сравниванию.
В том то и дело, что это скорее код, чем данные )
TeX понимает, как нарисовать результат интепретации исходника на бумаге, семантика ему не нужна.
В Commodore 64 из коробки обычный построчный Бейсик. Наверное, был сторонний софт с "обычным" редактированием текста - всё-таки у него даже дисковод был - но он же появился после того, как железку задизайнили.