Pandoc: ICML: Option to disable "> first" styles

[cprecioso]

This is a feature request. InDesign and InCopy, since CC2019, allow for a new option in paragraph styles for _space between paragraphs of the same style_, in addition to _space before_ and _space after_.

This renders the > first styles useless, as AFAICT they were created to solve the problem of creating space before lists without affecting spacing between items of the list. And now they're even annoying, as you can't use the _space between parapgraphs of the same style_, because the first item in the list is a different style.

It'd be great if there was an option to disable the creation of these > first styles; as I understand that many people might be in older versions of InDesign and these style might still be needed for them.

Pinging @mb21 as I can see in past issues he's the one in charge of the ICML writer.

[mb21]

since CC2019, allow for a new option in paragraph styles for space between paragraphs of the same style, in addition to space before and space after.

nice! so that means we don't need to implement something like https://github.com/jgm/pandoc/issues/2315 anymore?

would you like to add a new section to https://github.com/jgm/pandoc/wiki/Importing-Markdown-in-InDesign, explaining that?

[mb21]

That leaves the question of how to remove the generation of the > first styles without breaking things for existing users... we could add an extension, but seems like a hack to add an extension only for backwards-compatibility.

[cprecioso]

Nope, I don't think #2315 is necessary anymore!

I didn't even know there was a wiki page of this 😄. I'm okay with writing the section on the wiki if needed, but I don't know clearly what I would write. This option is together with the _space before_ and _after_ ones, so it'd be pretty hard to miss if you're already customizing those.

[mb21]

cool, yeah if you could just that screenshot (maybe in english) along with a sentence or two, that would be great. Just something we can link to from #2315... apparently the users that created that weren't aware of the option.. (or were mislead by the > first)

[cprecioso]

Okay, I'll do later as I'm in the middle of a working day and can't change the language right now.

Just an annotation that because the > first is a distinct style, between the first item and the rest of the list, the before and after spaces will still be in effect, so it might be confusing, but I think I can word it okay.

That leaves the question of how to remove the generation of the > first styles without breaking things for existing users... we could add an extension, but seems like a hack to add an extension only for backwards-compatibility.

About this, I really don't know... I don't know if pandoc has a policy of supporting old versions of the output formats, or if the last version is supposed. Else, -t icml-first_style sounds fine for me; or ultimately, maybe a variable set in the metadata block, if you don't want to implement the extension system?

I'd really like to help but Haskell is quite impenetrable for me. :/

[mb21]

what do you think @jgm?

[p3palazzo]

@mb21 @cprecioso though I agree list > first is now deprecated, the ICML writer could use a First paragraph output format such as there is in the DOCX and ODT writers; it is useful when you don't want to indent the first line of a paragraph that comes right after a heading, but do want the following paragraphs to have an opening indent; InDesign still can't handle this particular variation from within a single Paragraph style.

[jgm]

I don't know anything about ICML or In Design. If this is a feature that is new in 2019, it's probably not good to remove support for older versions. In addition, I want to echo @p3palazzo's concern: distinguishing the first paragraph is important for correctly handling indentation, as well as line spacing.

[cprecioso]

would you like to add a new section to jgm/pandoc/wiki/Importing-Markdown-in-InDesign, explaining that?

Done

[cprecioso]

@jgm then maybe it is worth it to implement an extension system? Same as -t markdown+extension_name-extension_name. Is this a pandoc-provided facility or each writer has to create it itself?

[nathan-artist]

I am still using an older version of InDesign, and I imagine I am not the only one using an older version, so I agree that it is not good to remove support for older versions of InDesign.

The last time I checked, which was last year, Pandoc's ICML writer writes header tags that indicate that the output is DOM version 8.0 for InDesign CS 6.0, as follows:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <?aid style="50" type="snippet" readerVersion="6.0" featureSet="513" product="8.0(370)" ?>
    <?aid SnippetType="InCopyInterchange"?>
    <Document DOMVersion="8.0" Self="pandoc_doc">

I think that DOM version 8.0 should remain the default (because it's something that I can use with the version of InDesign that I use!) but if you are going to implement an optional feature for newer versions of InDesign, you will want to change this header information in the output.

[lrosenthol]

@jgm removing the use of first styles from the ICML writer is pretty easy....but I agree that it should be an option. Is there a standard way to add per-writer settings? Is there a cookbook on how to do it or some set of code that I can follow to address this.

NOTE: this change wouldn't impact that version of the ICML @nathan-artist - though supporting #6607 may (still working through the implementation details with the Id team)

[mb21]

Is there a standard way to add per-writer settings?

quite a few extensions can be used in different writers, so the answer is no.

You can take a look at this commit, where a new extension was added (along with a little bit of implementation code). guess in the README it should go into this section? https://pandoc.org/MANUAL.html#other-extensions

As always, the trickiest part is naming ;-) Something like icml_sibling_styles ?

[lrosenthol]

thanks @mb21 - I looked that over and I think I see what needs to be done. As soon as my first PR is cleared, I'll take a crack at this one.