request: syntax for centering text #719
Comments
|
Better: |
|
Reasons why I like this syntax:
|
|
BackgroundIntermixing HTML tags (or TeX macros) with Markdown to center objects (text, images, tables) is a format-dependent solution to the centering text problem. It should be possible to write a single source file in Markdown and generate all formats that publishers require and Pandoc can export, without resorting to format-specific markup. The publishing industry, academics, technical writers, poets, and bloggers use centering extensively. To wit, centered text alignment dates back 500 years, if not earlier. Centering is not an arbitrary formatting feature, but integral to professionally typeset manuscripts. Elements centered in a proper manuscript format include:
Additionally, screenplay cover pages are entirely centered. Markdown should standardize text justification (left, right, center) before competing, and perhaps conflicting, syntaxes flourish. PrecedentCentered text exists in various Markdown flavours:
And is actively employed by various web sites:
SyntaxThis section describes several syntax mechanisms for text justification. Justified PipesThis justified pipe syntax builds on Pandoc's existing block syntax. Mirrored ArrowsThe table colon syntax can be applied to enhance the arrows with left/right justification: This is compatible with countless existing documents that already use centering. Mirrored Angle BracketsA simpler syntax to the mirrored arrows is used by screenplay writing software: Arrow BlockA single token to denote centering: Double-colon Prefix BlockA regular block of text is centered using a prefix: Ini-style Prefix BlockA combination of Windows This could be extended: Cat WhiskersA single token to denote centering: Attribute BlockUse CSS-style attributes: Arguments AgainstThis section describes the arguments against including a centered Markdown syntax. Non-Descriptive| Centering is a presentational instruction, and Markdown should separate semantics from presentation This is the strongest argument against its inclusion, but still falls a bit short. Consider: | Tables | Are | Cool |
|----------|:-------------:|------:|
| col 1 is | left-aligned | $1600 |
| col 2 is | centered | $12 |
| col 3 is | right-aligned | $1 |The Markdown strongly suggests the content is tabularized data and should be presented as such. How the table looks (cell padding, spacing, background colours, bold headers, borders, etc.) is definitely outside the scope of Markdown. However, everyone who types up such ASCII tables is aware that a single comma-delimited paragraph will not be generated (illegible to humans and impossible to machine read, generically). Some tables can be presented in other forms, such as pie charts, but those are likely exceptions. On a similar token, No semantic meaning is attached to To say that Markdown completely separates content from presentation is slightly disingenuous because source code blocks and monospaced fonts are practically inseparable. Adding a hint to center text can be considered a separation of content from presentation. Text marked down as centered doesn't have to be presented as centered any more than a code block must be presented in a monospace font or Feature Complete
By this reasoning, lambda expressions should not be added to existing programming languages. Nobody has proposed hard limits on what Markdown is meant to accomplish. Markdown has a stated purpose: to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid X/HTML. Yet, as Pandoc has shown, Markdown can also be a simple, human-readable, filetype-agnostic structured text format. Slippery Slope
First, the slippery slope is a logical fallacy. Second, mixing HTML tags and Markdown eliminates the possibility of a single, pure Markdown source to automatically generate a wide variety of output formats. Arguments ForThis section describes the arguments for including a centered Markdown syntax. PrecedentA number of precedents currently exist in the wild for a centering syntax. While this is argumentum ad populum, it certainly speaks to a practical need in the real world. Competing SyntaxDeveloping a standard in Markdown itself should help prevent competing standards from emerging. Historic TypographyCentering has been in use since before the printing press. Although this falls under argumentum ad antiquitatem, again, it speaks to the practical need to center text. Single SourceThere is no way to write a single, pure Markdown file and generate centered text in a wide variety of output formats (from XHTML to ConTeXt) to meet various industry needs. Intermingling format-specific tags or macros defeats the purpose of a single source. ProfessionalismProfessionally typeset manuscripts and screenplays require certain aspects to be centered. Usage BarrierMost people aren't programmers; there are people who don't have the capacity or desire to even learn how to mark up text. (This is why Microsoft Word and other such WYSIWYG word processing software is so popular and widely used.) Forcing people to embed fragments of indescribably foreign code to do something as simple as center (or justify) text builds a high barrier to using Markdown. Microsoft's StrangleholdCurrently, Microsoft Word dominates manuscript submission requirements (Analog, Lightspeed, Mothership, Fantasy Scroll, Flash Fiction, New Accelerator, Tor, Asimov, and many others strongly prefer or outright demand .doc or .docx manuscript submission formats). This will not change until a viable, simpler standard is created. RelatedMost of the content in this comment is a summary of the following threads: |
|
I would also have noted that the formatting, not semantic, super- and sub-scripting exist already in pandoc and in various markdown flavors. |
|
People will want to write their centered text in the center, like this: rather than because it just looks better that way. But with the mirrored arrows syntax, how can you tell if it's meant to be centered text or verbatim text? Another aspect of |
I prefer the | How can you tell if [mirrored arrows are] meant to be centered text or verbatim text? Good point. Also, some text editors might confuse What are the next steps? Vote for what syntax to use, get agreement from the core developers, develop a prototype integration, or something else? |
|
People like doing complex formatting, where markdown cannot |
What "people"? That presupposes a certain type of people who want to use Markdown. Name them. Here are classes of people whose writing or industry could benefit from the simplicity of Markdown formatting:
Here are classes of people whose work sometimes requires complex formatting, which makes Markdown unsuitable:
Nobody has drawn a line in the sand that states, "Markdown shall not do this." Markdown has no scope. Rather, subjective terms like "simple" and "human readable" attempt to reign in its extents. This will cause endless debate whenever additions are proposed. The former planet Pluto was considered a planet until the word planet was given a formal definition. Markdown suffers in the same way: it lacks formal definition. That "Markdown cannot do this" doesn't mean "Markdown shall not do this." Also... You say, "It can't." I say, "It can." That's not a debate with any technical merit or hints of rational thought: it's a pointless religious debate that cannot be resolved in any meaningful way. |
There's no voting, per se. From what I've seen, feature requests may be left open for a while to give folks time to mull them over, discuss, and possibly create patches. Of course, it's easy to add features but difficult to remove them (once folks are using them). Also, some requested features would be extremely useful, but might make the pandoc-markdown format too noisy, or clash with some other existing usage, or break backcompat, or not work with all (enough?) output formats.
IMO, pandoc-markdown balances somewhere between capturing common usage (what you'd normally/naturally write in a plain text email or an online comment), and providing enough features to help you get away from Word/LaTeX/HTML. While looking good doing it. ;) A difficult task. |
|
What is the current status for this? Markdown centering is something I would really like to see. It is very important for scientific content when you want to center figures for example! |
|
@tgy, as far as I remember, images accept attributes, so you can use attributes to center images. I think it is way more important (and more useful) that paragraphs accept attributes than they may be aligned. |
|
I just found this issue, while looking for solutions to my problems. |
|
Probably this should be tagged "AST Change". |
|
@ickc |
|
I'm not the core-developers, so I can't tell. That said, I guess the priority will be low, considering that any "AST Change" level of issues are complicated and there are already many of them (in addition to the complexity involved, I would guess that a lot of thought would be given before any AST Change is made to get it right the first time). Just to illustrate the level of complexity: all reader/writer pairs for each format is needed to be updated, and depending on exactly what is involved, the tools built around pandoc needed to be updated too: pandoc-templates, pandoc-citeproc, any "filter framework" that parses the pandoc AST into its own, e.g. panflute, etc. However, we can bend it such that it doesn't require an AST Change. e.g. just use a Div with class "center": Cons:
Pros:
|
|
We might implement this at some point, but I'd advise using filters for now. |
|
If issue #168 is resolved, then this issue can be closed, as an additional syntax for centering would be superfluous: |
Not necessarily. It depends if one accepted the suggestion of using generic Div and a class to centering, or want a dedicated syntax for centering, similar to LineBlock (the original suggestions make comparison to LineBlock, and consider centering/LineBlock to be special cases of justifications). In terms of AST, while one could imagine LineBlock syntax can be parsed as a Div with a certain class, but pandoc actually assigned a special element to it, which by the way cannot carries attributes at the moment. So to solve the centering problem in terms of AST, one can tries at least these methods:
So when I suggest using a Div, it is the 2nd approach. But the 3rd approach could as well be a viable option, especially if the syntax of centering will be similar to LineBlock's. So there're 2 related considerations:
If the answers are no to both, then using Div with classes is the simplest solution, and is a solution that can happens right now. Lastly, I have a related question: what if one want to center/right-justified other kind of elements, say Headings? If this is desirable, then using a class can immediately generalize it to any pandoc elements that can carries attributes, while overloading LineBlock will limit it to just LineBlock-like texts. |
Yes, this is the reason I included an example block, to show the syntax that would obviate this feature request:
Headings and other elements can be styled without a specific class attribute because they can be uniquely referenced. This applies equally to HTML and TeX code. It's even possible to style the same heading level in different ways: Using CSS3, center every second heading as follows: |
|
@DaveJarvis, ; --- div {.centered}
...compared to @uvtc's for example, |<> centered
|<> also ignores leading space
|<> last lineThe latter is definitely better fitting the philosophy:
I remembered @jgm mentioned somewhere (probably in CommonMark when commenting on Microsoft's another attempt on a tool similar to pandoc/MultiMarkdown) that using English words to describe what it is is worse than using a syntax to show it (e.g. non-English documents). While we are talking about a class here (not just some syntax using English word), when someone read it as a plain-text, it is the same to them. i.e. all they read is just an English word. Just to make it clear, I am not opposing to either approaches (that's why I suggested using a Div instead earlier). But I'm just pointing out the others might have other considerations. So we need to wait if they have any other opinions before closing it. And even if one settled to use classes for centering, should one do it with Div, or LineBlock (LineBlock cannot carries attributes right now, but it seems that it will eventually be supported)? That's the "philosophical" part I mentioned above. |
I understand, thank you for clarifying.
That is an issue. Perhaps @uvtc, @jgm, or @jgruber might want to chime in with their thoughts on this potential divergence from Markdown philosophy. |
|
+++ ickc [Jan 07 17 12:26 ]:
I remembered @jgm mentioned somewhere (probably in CommonMark when
commenting on Microsoft's another attempt on a tool similar to
pandoc/MultiMarkdown) that using English words to describe what it is
is worse than using a syntax to show it (e.g. non-English documents).
While we are talking about a class here (not just some syntax using
English word), when someone read it as a plain-text, it is the same to
them. i.e. all they read is just an English word.
My main objection to the use of English words is that not
everyone writes in English.
One nice thing about Markdown as opposed to, say, LaTeX, is
that if you're writing in (say) Swedish, your document isn't
littered with English words. It's ALL in Swedish, with some
punctuation. People have sometimes commented on how nice
this is.
|
How the "poem" is presented (centered, right-justified, etc.) is independent of the Markdown. Any language can denote that the paragraph is a stanza. That is to say, no formatting instructions are present, though |
|
I came across this when looking for line block related issues to check if another issue I have had been reported. I have not read everything here (it's a lot!) but I thought that now when we have a nice div syntax what about making a class like In LaTeX that would presumably be the I think that in HTML it should perhaps be up to the user to implement/link the necessary CSS based on the class rather than polluting the default template with more in-document CSS. Remember that it's hard or impossible to override in-document CSS, whether in the header or in a |
|
A workaround is to use a table with no header and a single centred column. | |
|:---:|
| This
| text
| is
| centered
|
|
Any updates on this? (how to center text on LaTeX via pandoc) I wonder if these fenced_divs can be used somehow: #4037 Or pehaps this pandoc-latex-environment, to somehow convert a div class "center" to the \begin{center} ... on LaTeX: https://github.com/chdemko/pandoc-latex-environment/wiki Sorry, I don't know much of the internals of pandoc (yet), and couldn't make any of them work... can someone give a clue on the latest advances here? |
|
@igormcoelho, you can create a simple Lua script to convert custom blocks to centred text. Here's an example that creates a custom inline image based on a fenced div: local lines_to_blocks = {
Image = function( el )
return {
pandoc.RawInline( "tex", "\\inlineexternalfigure[" .. el.src .. "]" )
}
end
}
function Div( el )
local kls, _ = el.classes:find_if(
function ( c )
return string.match( c, "^image%-" )
end
)
if kls then
return pandoc.walk_block( el, lines_to_blocks )
end
endSee also @jgm's #2106 (comment). Save the file as pandoc --lua-filter=centre.luaThis then parses the following block: ::: image-inline
:::To produce: \inlineexternalfigure[../climate/graph]Feel free to use this example to produce centred LaTeX code. Note that |
|
Thanks @DaveJarvis for the fast and detailed response. (@obj) $maximize \sum_{i \in X} p_{i}$In fact, I could use \begin{equation} ... here, I would be centered in LaTeX, but totally unreadable for markdown, and I want to do that in a way that is compatible with markdown too, because we have both users editing the document. |
|
|
I see that, problem is that I'm using (@obj) to create a label that will be further cited: I think that double $$ environment in LaTeX do not allow labels... |
|
Have you tried using See http://lierdakil.github.io/pandoc-crossref/#equation-labels |
|
I'm glad to hear that it helped! |
|
If my suggestion (here, above, from 2013!) to build upon line block syntax is not desirable (possibly because adding a three-character
Give all that, how about this simple rule: if you follow a horizontal rule marker with spaces followed by text, then the text gets centered and the horizontal rule itself is omitted. That would be for single-line centered text only, though I suppose could also support a "lazy-style" (multi-line) variant.
Does that cause ambiguities with any other pandoc-markdown syntax? I think it's pretty clear it's not an HR. Does it break anything? The only possible issue that comes to my mind is that So, this is a simple solution that's:
What do you think? |
|
John Gabriele <notifications@github.com> writes:
Does that cause ambiguities with any other pandoc-markdown syntax? I think it's pretty clear it's not an HR. Does it break anything? The only possible issue that comes to my mind is that `---` usually gives me an em-dash.
Well, in addition,
* * * * hi
currently gives you a nested list in pandoc and most other
markdown implementations.
|
|
Perhaps some variation of the table syntax that renders a paragraph rather than a table. |
|
@jgm Ah, right. Thanks for pointing that out. I see there's the same issue with It's difficult to come up with light, sensible, obvious markup for centered text, which also degrades gracefully (for implementations that don't support it) and at the same time looks "classic" such that it will be readily adopted (begins being used not only because it's handy but because it just "looks right"). I think the difficulty is partly because most folks would, in an email, probably just write their "centered text" indented with spaces and be done with it. @sjackman , an issue with re-using table syntax is that, aside from possible ambiguity with table syntax, you are also then back to using multi-character markers ( Remember that the primary table syntax in pandoc-markdown is so simple that you may not even realize you're using it. :) The other table syntaxes (like Updated tightened-up suggestion: If a horizontal rule marker of the kind containing no interspersed spaces is followed by text, then the text is centered and the HR marker itself is omitted. This is simple, looks good, and seems obvious that it's meant to indicate centered text. It feels markdownish:
And I think, due to the similarities between between HR's and centered text, it works pretty well. |
I tend to agree with this. That's why I'm not so sure we need new syntax. Following the precedent of smallcaps, underline and columns, I would be fine with using native div and span syntax and use something like the following: Currently, you need to write a filter to handle this, but this could potentially be handled by pandoc itself, if we decide it's common enough. |
|
The following mixes content with presentation: ::: centered :::
my text
:::As does: ::: centered small
Copyright notice
:::Consider, instead: ::: footer
Copyright notice
:::That is, rather than using the word "centered" to denote centered text, perhaps emphasis can be placed on separating content from presentation? Why does the text need to be centered? Is it a quotation? An indicator that a line of reasoning has stopped? A stanza from a poem? A header? A call-out? A warning? |
|
Couldn't this be achieved using a heuristic instead of adding new syntax? Here's one approach: For each line in a line block, we determine alignment based on the number of leading space characters, and the implied number of trailing space characters. Leading spaces are the number of spaces between the pipe and the first non-space character (if any). Implied trailing space characters are equal to the max line length in the block minus the position of a given line's last non-space character. For example, consider this line block: In this block, the max line length is 13 ("right"). For each line in this block, we have the following number of leading and implied trailing spaces: For each line, the alignment is determined as follows:
This would give each line in the line block the expected alignment, using only the most natural of formatting. The main tricky bit seems to be defining "approximately equal" for determining if there are roughly the same number of leading and trailing spaces. It would admittedly be a bit painful to manually align your text to the right, but it would also be what you'd have to do to get a nice-looking right-alignment in plain text. Perhaps editor macros/plugins could help with the task? Thoughts? I'm not a Markdown expert so I'd guess I'm missing something obvious.... |
|
@joshhansen I'm sorry, but I think that particular suggestion fails on two counts:
|
|
Good point. This could be addressed by only considering explicitly present trailing spaces rather than implied trailing spaces (implied by a line being shorter than the maximum line length in the block). Consider this version (note the trailing spaces after "centered"): The alignment rule then becomes: function alignment(line_length, max_line_length, leading, trailing) {
if(line_length == max_line_length && leading > 1) {
if(trailing == 0) {
return "right";
else if(leading approximately equals trailing) {
return "center";
}
}
return "left";
}I'm not sure what you mean by "a centered paragraph with wrapped lines". Can you please expound? Of course, as with many other aspects of pandoc, this would probably only make sense as an extension that's off by default. You mentioned poetry---that's my current use case, and I would find an extension like this incredibly useful. |
|
Is this still being considered? |
Jokes aside: |
A simple filter could be this: function Div(el)
local class = el["c"][1][2][1]
if class == "center" or class == "right" then
local align = class
el["c"][1][2] = {} -- remove class
el["c"][1][3] = {
{ "style", "text-align:"..align..";" }, { "custom-style", align }
}
--[[ add attributes both for html and for docx (you need to define "center"
and "right" custom styles in your reference docx file) ]]
return el
end
return nil
endIt works with conversion to both html and docx, but to make it work with docx you need to define "center" and "right" custom styles in your reference docx file. If you start the text line with a ::: right
\ this text is right-aligned
:::
::: center
\ centered!
:::
|
|
Hello to all, |
|
After all it is very simple to make work: local center_for = {
latex = {
pre = pandoc.RawBlock('latex', '\\begin{center}'),
post = pandoc.RawBlock('latex', '\\end{center}'),
},
-- add more as needed...
}
function Div (div)
if div.classes:includes('center') then
if center_for[FORMAT] then
local rv = {}
if center_for[FORMAT].pre then
rv[#rv+1] = center_for[FORMAT].pre
end
rv[#rv+1] = div
if center_for[FORMAT].post then
rv[#rv+1] = center_for[FORMAT].post
end
return rv
end
end
return nil
endNot even 25 lines, and then I even made it customizeable. |
|
This would definitely be nice to have |
|
God, this has been open for over a decade. ffs, add centering already!! |
|
I have found this series of filter in the official page for new pandoc filters: https://github.com/pandoc-ext/fonts-and-alignment It defined various classes for fonts and alignments, including centering |
and others
Now that Pandoc supports line blocks, here's some syntax that might work nicely for left/center/right -justifying lines:
Thoughts?
The text was updated successfully, but these errors were encountered: