Tufte-css: Уценка к этому?

Pandoc предлагает шаблоны для построения, поэтому создание шаблона Tufte pandoc должно быть простым.

@langford, оказывается, уже существует шаблон Tufte для Pandoc, подробности о преобразовании Markdown / Multi-Markdown в стиль Tufte см. в моем комментарии: https://github.com/daveliepmann/tufte-css/issues/30#issuecomment - 128718117

@ xHN35RQ после небольшого изучения, шаблоны pandoc кажутся неправильным способом для этой функциональности: шаблону дается строка $body$ и он в значительной степени ожидает, что просто поместит текст до и после него, и не кажется предназначен для фактического управления текстом, созданным из уценки. Вы могли бы использовать пользовательские писатели pandoc, которые вы можете писать (аллилуйя) на Lua. Я написал пользовательский писатель barebones, который просто реализует боковые заметки и добавляет тег article : см. Суть . Я надеюсь расширить его, продолжая писать tufte-css, чтобы включить все предоставляемые функции - в идеале без необходимости изменять что-либо о pandoc markdown или его читателях.

(Для полноты я мог бы упомянуть фильтры pandoc как что-то, что в конечном итоге может потребоваться для полного создания HTML-кода с поддержкой tufte-css из pandoc markdown, но, вероятно, только для очень сложных вещей. Фильтры управляют AST, прежде чем AST передается настраиваемому писателю Правильное место для добавления заметок в стиле tufte-css было в настраиваемом писателе, а не в качестве фильтра.)

@fasiha хорошая работа. Вы сделали многообещающее начало здесь. : +1:

Я не думаю, что в Markdown есть легкодоступный эквивалент tufte-css _sections_, то есть группировка абзацев и заголовков. Но я думаю, что мне нравится идея разделов, я думаю, что дополнительный уровень организации документов будет полезен в будущем.

Есть предложения от сообщества, как можно указать разделы в Markdown?

@fasiha Как насчет фильтра, который переносит элементы заголовка и все элементы абзаца до следующего элемента заголовка? Затем оберните их в теги <section> (или другие пользовательские теги <div> ) и примените к нему нужный CSS?

Спасибо, что взвесили @vyp. Судя по тому, что я читал на первой странице tufte-css, section может захватывать более одного заголовка или абзацев без заголовка. То есть это не просто контейнер заголовка и содержимого. В моем документе я просто встраиваю <section> как необработанный HTML в Markdown - для этого, я думаю, я могу принять необработанный HTML.

@fasiha Ах, извините, что вы правы. Поскольку раздел определяется как «логическая группировка текста и заголовков», невозможно определить, что именно представляет собой раздел в документе без участия человека (т.е. мы фактически размечаем разделы как семантическую информацию, точно так же, как мы делаем разметку с помощью выделение звездочками или подчеркиванием). И да, я не знаю какого-либо ранее существовавшего синтаксиса для этих «разделов» в каком-либо варианте уценки, так что хороший улов.

В этом случае лучше всего использовать необработанные теги <section> (кроме определения собственного синтаксиса, подобного уценке, и написания для него парсера).

Другой способ - использовать тот факт, что tufte говорит, что он использует h2 для «заголовков разделов», поэтому, возможно, «раздел» можно определить как тег h2 и все до следующего тега h2 и так далее. Но я не уверен, что автор tufte имел в виду именно это.

Элементы H2 не являются надежными источниками разграничения сечения. Например, в некоторых документах вместо этого используются интервалы «новой мысли». Я уверен, что в дикой природе появятся и другие варианты.

8 августа 2015 г., в 23:49, vyp [email protected] написал:

@fasiha Ах, извините, что вы правы. Поскольку раздел определяется как «логическая группировка текста и заголовков», невозможно определить, что именно представляет собой раздел в документе без участия человека (т.е. мы фактически размечаем разделы как семантическую информацию, точно так же, как мы делаем разметку с помощью выделение звездочками или подчеркиванием). И да, я не знаю какого-либо ранее существовавшего синтаксиса для этих «разделов» в каком-либо варианте уценки, так что хороший улов.

Использование сырых

Теги - лучшее, что можно сделать в этом случае (кроме определения собственного синтаксиса, подобного уценке, и написания для него парсера).

Другой способ - использовать тот факт, что tufte говорит, что он использует h2 для «заголовков разделов», поэтому, возможно, «раздел» можно определить как тег h2 и все до следующего тега h2 и так далее. Но я не уверен, что автор tufte имел в виду именно это.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Я предполагаю, что если кто-то хочет избежать использования тегов <section> в своей уценке, некоторый синтаксис, похожий на <hr> , может быть несложно реализовать. Синтаксис для <hr> в основном состоит из «трех или более дефисов, звездочек или подчеркиваний в отдельной строке». Так, например, вы можете произвольно определить разграничение «раздела» как «три или более знаков равенства» (или что угодно, что вам больше нравится), а затем использовать фильтр pandoc, чтобы обернуть все между каждой парой этих абзацев только знаками равенства.

Я выбрал только «строку со знаками равенства», потому что думаю, это то, что могло бы _выглядеть_ при разделении разделов обычным текстом? И поскольку pandoc markdown будет анализировать это как только абзац, то есть ваш фильтр может просто проверять каждый абзац, если в нем есть только знаки равенства или нет, и если он состоит только из знака равенства, предположим, что это часть демаркации раздела.

Привет всем (и спасибо @daveliepmann за то, что указал мне на эту glasseye , в котором я использовал Tufte.css (так что спасибо всем за это) и в который я стремился интегрировать markdown, d3 и макет Tufte. На данный момент это прототип с большим количеством разрезов на углах. Когда у меня есть момент, я бы хотел очистить код и немного рационализировать дизайн (на этом этапе я буду рыться в ваших комментариях к CSS). Но я хотел сначала посмотреть, стоит ли это делать, и я думаю, что это так. В любом случае хотелось бы получить отзывы.

Будет ли reStructuredText более податливым, чем Markdown, для тех аннотаций, которые здесь необходимы?

@coppeliaMLA Спасибо за упоминание glasseye, это невероятная работа.

@rbcarson Я не ОП, но если вопрос адресован всем присутствующим, и вы хотите узнать мое мнение, я лично не знаком с реструктурированным текстом, поэтому не могу точно сказать. Но, возможно, вы правы, базовый синтаксис уценки, созданный Грубером, Шварцем и его коллегами, я думаю, был вдохновлен тем, как люди писали (простой текст) электронные письма «тогда». Таким образом, оно начиналось только настолько сложным (или «способным»), насколько могло бы быть обычное электронное сообщение, а не с исследовательской работы или какой-либо другой формы письма, в которой используется много второстепенных примечаний или иным образом следует или имеет смысл со стилем Тафте.

Итак, с годами существует очень много другого синтаксиса, который вы можете втиснуть в «уценку», потому что вся суть в том, что он должен быть читаемым в текстовой форме. Как визуально передать заметки на полях в виде обычного текста? Тем не менее, я считаю, что расширенная уценка pandoc действительно хорошо поработала в этом отношении.

Итак, я думаю, что в реструктурированном тексте есть что-то, называемое директивами или что-то в этом роде, что позволяет вам создавать синтаксис (или что-то в этом роде?) Для определенного типа данных? Если это отчасти так, то да, я думаю, что реструктурированный текст здесь, вероятно, более податлив. Но, как я уже сказал, у меня нет большого опыта в этом, поэтому я больше не могу вам помочь.

restructuredText был бы бесполезен для моих целей, которые являются проектами, уже задокументированными в markdown

17 августа 2015 г., в 4:24, vyp [email protected] написал:

@coppeliaMLA Спасибо за упоминание glasseye, это невероятная работа.

@rbcarson Я не ОП, но если вопрос адресован всем присутствующим, и вы хотите узнать мое мнение, я лично не знаком с реструктурированным текстом, поэтому не могу точно сказать. Но, возможно, вы правы, базовый синтаксис уценки, созданный Грубером, Шварцем и его коллегами, я думаю, был вдохновлен тем, как люди писали (простой текст) электронные письма «тогда». Таким образом, оно начиналось только настолько сложным (или «способным»), насколько могло бы быть обычное электронное сообщение, а не с исследовательской работы или какой-либо другой формы письма, в которой используется много второстепенных примечаний или иным образом следует или имеет смысл со стилем Тафте.

Итак, с годами существует очень много другого синтаксиса, который вы можете втиснуть в «уценку», потому что вся суть в том, что он должен быть читаемым в текстовой форме. Как визуально передать заметки на полях в виде обычного текста? Тем не менее, я считаю, что расширенная уценка pandoc действительно хорошо поработала в этом отношении.

Итак, я думаю, что в реструктурированном тексте есть что-то, называемое директивами или что-то в этом роде, что позволяет вам создавать синтаксис (или что-то в этом роде?) Для определенного типа данных? Если это отчасти так, то да, я думаю, что реструктурированный текст здесь, вероятно, более податлив. Но, как я уже сказал, у меня нет большого опыта в этом, поэтому я больше не могу вам помочь.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

@coppeliaMLA очень интересно !: используйте pandoc для вывода HTML со специальными тегами, а затем в качестве второго этапа используйте другую программу для расширения специальных тегов до Javascript и HTML. Мой подход заключался в том, чтобы создать пользовательский писатель Pandoc, который использует специальные теги, эффективно выполняя glasseye.py в Lua, используя Pandoc AST вместо синтаксического анализа BeautifulSoup, но похоже, что glasseye в основном работает нормально. Я постараюсь глазировать мои документы и сообщать вам в репозитории о любых проблемах. То, что сложно сделать в Pandoc writer, может быть проще выполнить постобработку, и наоборот, но единственный способ узнать это - написать кучу документов :)

@fasiha спасибо. Ваш путь действительно кажется более эффективным, и я думаю, что, возможно, я смогу в конце концов пойти в этом направлении. Я выбрал питон, так как он позволил мне быстро создать прототип. Но, как вы говорите, экспериментирование с большим количеством документов позволит отточить лучший метод. Я планирую использовать его в своей повседневной работе, насколько это возможно, чтобы увидеть, к чему он меня приведет. Было бы здорово, если бы вы могли попробовать. Люблю слышать, как дела!

См. # 31, а также # 58

Для чего это стоит: я просто собрал tufte-pandoc-css чтобы решить проблему написания боковых заметок в Markdown. Это просто демонстрация того, как использовать собственный фильтр Pandoc, который я написал под названием pandoc-sidenote .

Чтобы увидеть это в действии:

• Повторная реализация tufte-css / index.html в Markdown со вкусом Pandoc
• Демонстрация некоторых других функций Pandoc , таких как выделенные синтаксисом блоки кода.

@jez Круто! Я посмотрю, смогу ли я найти проект, чтобы развлечь его.

Только что нашел эту ветку через Google

Возможно, вы захотите взглянуть на xmark : он преобразует Tufte -CSS через XSLT.

@vieiro вау, это хорошо. Отличная работа 👍🏻