Tufte-css: ¿Rebajas para esto?

Pandoc ofrece plantillas para construir, por lo que crear una plantilla de Tufte pandoc debería ser sencillo.

@langford resulta que ya hay una plantilla de Tufte para Pandoc, vea mi comentario aquí para obtener detalles sobre cómo convertir Markdown / Multi-Markdown en estilo Tufte: https://github.com/daveliepmann/tufte-css/issues/30#issuecomment - 128718117

@ xHN35RQ después de analizarlo un poco, las plantillas de pandoc parecen la vía incorrecta para esta funcionalidad: a una plantilla se le asigna una cadena $body$ y prácticamente espera poner texto antes y después, y no parece destinado a manipular realmente el texto generado a partir de la rebaja. Usaría escritores personalizados de pandoc que puede escribir (aleluya) en Lua. He escrito un escritor personalizado básico que simplemente implementa notas al margen y agrega la etiqueta article : ver la esencia . Espero ampliar esto mientras sigo escribiendo tufte-css para incluir todas las funciones proporcionadas, idealmente sin tener que modificar nada sobre pandoc markdown o sus lectores.

(Para completar, podría mencionar los filtros pandoc como algo que eventualmente podría ser necesario para producir completamente HTML habilitado para tufte-css a partir de pandoc markdown, pero probablemente solo para cosas muy complicadas. Los filtros manipulan el AST, antes de que se le dé un AST a un escritor personalizado . El lugar correcto para hacer notas al margen de estilo tufte-css fue en el escritor personalizado, no como un filtro).

@fasiha buen trabajo. Ha tenido un comienzo prometedor aquí. : +1:

No creo que haya un equivalente fácilmente disponible a tufte-css _sections_ en Markdown, es decir, una agrupación de párrafos y encabezados. Pero creo que me gusta la idea de las secciones, creo que tener un nivel adicional de organización de documentos será útil en el futuro.

¿Alguna sugerencia de la comunidad sobre cómo se podrían indicar secciones en Markdown?

@fasiha ¿Qué pasa con un filtro que lleva elementos de encabezado y todos los elementos de párrafo al siguiente elemento de encabezado? Luego, envuelva estos en <section> (o algunas etiquetas personalizadas <div> ) y aplique el css deseado a esto.

Gracias por opinar en @vyp. De mi lectura de la página principal de tufte-css, section puede capturar más de un encabezado, o párrafos sin encabezado. Es decir, no es solo un contenedor de encabezado y contenido. En mi documento, solo estoy incrustando <section> como HTML sin formato en Markdown por ahora; para esto, creo que puedo aceptar HTML sin formato.

@fasiha Ah, lo siento, tienes razón. Debido a que una sección se define como una "agrupación lógica de texto y encabezados", es imposible determinar qué es exactamente una sección en un documento sin la participación humana (es decir, nosotros realmente marcamos las secciones como información semántica, al igual que la forma en que marcamos con énfasis con asteriscos o guiones bajos). Y sí, no conozco ninguna sintaxis preexistente para estas "secciones" en ningún tipo de rebajas, así que buena captura.

Usar etiquetas <section> procesar es lo mejor que se puede hacer en este caso (aparte de definir su propia sintaxis similar a la de rebajas y escribir un analizador para ello).

Otra forma de hacerlo sería usar el hecho de que tufte dice que usa h2 para "encabezados de sección", por lo que quizás una "sección" se pueda definir como una etiqueta h2 y todo hasta la siguiente etiqueta h2 y así sucesivamente. Pero no estoy seguro de si esto es lo que pretendía el autor de tufte.

Los elementos H2 no son fuentes fiables de demarcación de secciones. Por ejemplo, algunos documentos utilizan intervalos de "nuevo pensamiento" en su lugar. Estoy seguro de que surgirán otras variaciones en la naturaleza.

El 8 de agosto de 2015, a las 23:49, vyp [email protected] escribió:

@fasiha Ah, lo siento, tienes razón. Debido a que una sección se define como una "agrupación lógica de texto y encabezados", es imposible determinar qué es exactamente una sección en un documento sin la participación humana (es decir, nosotros realmente marcamos las secciones como información semántica, al igual que la forma en que marcamos con énfasis con asteriscos o guiones bajos). Y sí, no conozco ninguna sintaxis preexistente para estas "secciones" en ningún tipo de rebajas, así que buena captura.

Usando crudo

tags es lo mejor que se puede hacer en este caso (aparte de definir su propia sintaxis similar a la de rebajas y escribir un analizador para ello).

Otra forma de hacerlo sería usar el hecho de que tufte dice que usa h2 para "encabezados de sección", por lo que quizás una "sección" se pueda definir como una etiqueta h2 y todo hasta la siguiente etiqueta h2 y así sucesivamente. Pero no estoy seguro de si esto es lo que pretendía el autor de tufte.

-
Responda a este correo electrónico directamente o véalo en GitHub.

Supongo que si alguien quiere evitar el uso de etiquetas <section> en su rebaja, alguna sintaxis similar a <hr> puede no ser difícil de implementar. La sintaxis de <hr> es básicamente "tres o más guiones, asteriscos o guiones bajos en una línea por sí mismos". Entonces, por ejemplo, podría definir arbitrariamente una demarcación de "sección" como "tres o más signos iguales" (o lo que prefiera), y luego usar un filtro pandoc para envolver todo entre cada par de estos párrafos con solo signos iguales.

Solo elegí "una línea de signos de igual" porque supongo que así es como se _vería_ dividir secciones con texto sin formato. Y debido a que pandoc markdown analizará esto solo como un párrafo, lo que significa que su filtro puede verificar cada párrafo si solo tiene signos iguales o no, y si solo está compuesto por un signo igual, asuma que esto es parte de una demarcación de sección.

Hola a todos (y gracias a @daveliepmann por señalarme este hilo). Puede que le interese mi paquete glasseye en el que he usado Tufte.css (así que gracias a todos por eso) y en el que he intentado integrar markdown, d3 y el diseño de Tufte. Por el momento, es en gran medida un prototipo con muchos cortes de esquina. Cuando tenga un momento, me gustaría limpiar el código y racionalizar un poco el diseño (en ese momento, revisaré sus comentarios sobre el CSS). Pero quería ver si valía la pena hacerlo primero y creo que sí. De todos modos me encantaría cualquier comentario.

¿ReStructuredText sería más adecuado que Markdown para el tipo de anotaciones que se necesitan aquí?

@coppeliaMLA Gracias por mencionar glasseye, es un trabajo increíble.

@rbcarson No soy OP, pero si la pregunta está dirigida a todos aquí y quieren mi opinión, personalmente no estoy tan familiarizado con el texto reestructurado, así que no puedo decirlo. Pero puede que tenga razón, la sintaxis básica de rebajas creada por Gruber, Swartz y compañía creo que se inspiró en cómo la gente escribía correos electrónicos (en texto plano) 'en ese entonces'. Por lo tanto, solo comenzó tan complejo (o tan 'capaz') como el mensaje de correo electrónico promedio podría ser, no un trabajo de investigación o alguna otra forma de escritura que use muchas notas al margen o que siga o tenga sentido con el estilo de Tufte.

Así que a lo largo de los años, hay mucho otro tipo de sintaxis que puede incluir en "rebajas" porque el objetivo es que se supone que es legible en forma de texto sin formato. ¿Cómo transmite visualmente las notas al margen en texto sin formato? Sin embargo, creo que la rebaja extendida de pandoc ha hecho un muy buen trabajo en este sentido.

Entonces, creo que el texto reestructurado tiene algo llamado directivas o algo así, que le permite construir sintaxis (¿o algo así?) Para un tipo particular de datos. Si ese es en cierto modo el caso, sí, creo que el texto reestructurado probablemente sea más adecuado aquí. Pero como dije, no tengo mucha experiencia con eso, así que no puedo ayudarlos más.

restructuredText sería inútil para mis propósitos, que son proyectos ya documentados en markdown

El 17 de agosto de 2015, a las 4:24 a. M., Vyp [email protected] escribió:

@coppeliaMLA Gracias por mencionar glasseye, es un trabajo increíble.

@rbcarson No soy OP, pero si la pregunta está dirigida a todos aquí y quieren mi opinión, personalmente no estoy tan familiarizado con el texto reestructurado, así que no puedo decirlo. Pero puede que tenga razón, la sintaxis básica de rebajas creada por Gruber, Swartz y compañía creo que se inspiró en cómo la gente escribía correos electrónicos (en texto plano) 'en ese entonces'. Por lo tanto, solo comenzó tan complejo (o tan 'capaz') como el mensaje de correo electrónico promedio podría ser, no un trabajo de investigación o alguna otra forma de escritura que use muchas notas al margen o que siga o tenga sentido con el estilo de Tufte.

Así que a lo largo de los años, hay mucho otro tipo de sintaxis que puede incluir en "rebajas" porque el objetivo es que se supone que es legible en forma de texto sin formato. ¿Cómo transmite visualmente las notas al margen en texto sin formato? Sin embargo, creo que la rebaja extendida de pandoc ha hecho un muy buen trabajo en este sentido.

Entonces, creo que el texto reestructurado tiene algo llamado directivas o algo así, que le permite construir sintaxis (¿o algo así?) Para un tipo particular de datos. Si ese es en cierto modo el caso, sí, creo que el texto reestructurado probablemente sea más adecuado aquí. Pero como dije, no tengo mucha experiencia con eso, así que no puedo ayudarlos más.

-
Responda a este correo electrónico directamente o véalo en GitHub.

@coppeliaMLA ¡ muy interesante !: usa pandoc para generar HTML con etiquetas especiales, y luego, como segunda etapa, usa otro programa para expandir las etiquetas especiales a Javascript y HTML. Mi enfoque ha sido hacer un escritor personalizado de Pandoc que consuma las etiquetas especiales, haciendo efectivamente glasseye.py en Lua, usando Pandoc AST en lugar del análisis de BeautifulSoup, pero parece que glasseye básicamente funciona bien. Intentaré revisar mis documentos y avisarle en su repositorio sobre cualquier problema. Las cosas que son difíciles de hacer en un escritor Pandoc pueden ser más fáciles de hacer después del procesamiento, y viceversa, pero la única forma de averiguarlo es escribir un montón de documentos :)

@fasiha gracias. Tu camino suena más eficiente y creo que posiblemente podría ir en esa dirección al final. Opté por Python, ya que me permitió crear un prototipo rápido. Pero como dices, experimentar con muchos documentos perfeccionará el mejor método. Estoy planeando usarlo durante la mayor parte de mi trabajo diario como sea posible para ver a dónde me lleva. Sería genial si pudieras intentarlo. ¡Me encanta escuchar cómo va!

Consulte el n. ° 31 y también el n. ° 58

Por lo que vale: acabo de juntar tufte-pandoc-css para resolver el problema de escribir notas al margen en Markdown. Es solo una muestra de cómo usar un filtro Pandoc personalizado que escribí llamado pandoc-sidenote .

Para verlo en acción:

• Una reimplementación de tufte-css / index.html en Markdown con sabor a Pandoc
• Una demostración de algunas otras características de Pandoc , como bloques de código resaltados por sintaxis.

@jez ¡Genial! Veré si puedo encontrar un proyecto para darle un giro a esto.

Acabo de encontrar este hilo a través de Google

Es posible que quieran echar un vistazo a xmark : que convierte markdown a Tufte-CSS vía XSLT.

@vieiro wow esto es lindo. Buen trabajo 👍🏻