Advanced image management approaches

[ptram]

@nontroppo

If you were aiming to use a markdown workflow

Actually, I’m after a hybrid way of working: mostly rich text (to avoid codes in the text and see an approximation of the final result), with the occasional use of code.

For the amount of styles/spans I have to use (for menus, commands, pages…), my markdown text would become unreadable. This would also contradict the initial aim of markdown, that was to remove most of the code and leave (a blogger) with the cleanest of the text documents.

@nontroppo

for EPub and HTML shouldn’t you just remove any sizing information and use CSS to specify viewport-relative sizes? The idea of cm or px or pt is less clear in an EPub, so just specify like width = 75vw to make it 75% of the viewport width

I like this, and would like a way to attach classes to images. It is like object styles in InDesign, and I hope it can translate to object styles when exchanging an IDML file between Scrivener and InDesign/Publisher.

(Ah, what a dream, Scrivener directly compiling to IDML…)

Not sure I’ve understood: can classes only be used in pure markdown? Or, as it seems to be shown in the Scrivener manual’s project, the ability of Scrivener to convert rich text to markdown during compile makes a hybrid approach possible? I think that this is absolutely possible with text styles, but not sure for images.

Would Compile format’s Replacements help with this? If I insert a linked image in a Scrivener document, and make it follow by a line of code written in the text, may I hope to simulate properties added to an image? Something like this in the (rich text) document:

[linked image]
{img-screen}

And then a replacement rule replacing [CR] [anything] [CR] [{img-screen}] with something like [CR] [div .class img-screen] [the same anything] [/div] in the compiled code?

@drmajorbob

I keep all images external (except a couple I use as info while writing), with a simple Replacement rule scheme for compiling them as needed.

But do you use images linked in the text, or, as it seems from the linked procedure, only placeholder tags? I’m still wondering if using these latter couldn’t be easier, despite having to run after the original image files to keep them open in another app.

@drmajorbob

I think it’s best not to let Scrivener take charge of resizing, and I don’t want the project to grow to gigabit size.

At least with page layout programs, this is normal practice: having a single source image, and resizing it in the page. A single source file, multiple uses.

Paolo

[nontroppo]

@ptram

Actually, I’m after a hybrid way of working: mostly rich text (to avoid codes in the text and see an approximation of the final result), with the occasional use of code.

Yes, I mean any writing style that uses markdown as the output mechanism (MMD, MMD → X, Pandoc → X). I always use hybrid markdown (Scrivener styles handle all my tasks, my editor has no markdown in it at all); this is still a markdown workflow. See §21.4 of the user manual for the “modes” of markdown.

Have you actually looked at the Scrivener User manual project or my Scrivener+Quarto template? A markdown workflow does not need any markup in the editor at all. You still seem to be assuming a markdown workflow requires writing markdown, that is not the case…

@ptram

I like this, and would like a way to attach classes to images.

I showed you this a few posts ago. You can add the class, ID and any attributes, either directly in the editor or using custom metadata. Now the problem is on the Adobe side, can it import well-formed HTML and use the class information or not? Honestly, Adobe and Affinity could greatly improve their interoperability, but they want to lock you into their walled garden…

---

Note: for ICML pandoc can generate both custom block and inline styles:

▶︎ pandoc -t icml

[Get out]{custom-style="Emphatically"}, he said.

<ParagraphStyleRange AppliedParagraphStyle="ParagraphStyle/Paragraph">
  <CharacterStyleRange AppliedCharacterStyle="CharacterStyle/Emphatically">
    <Content>Get out</Content>
  </CharacterStyleRange>
  <CharacterStyleRange AppliedCharacterStyle="$ID/NormalCharacterStyle">
    <Content>, he said.</Content>
  </CharacterStyleRange>
</ParagraphStyleRange>

You can see the custom-style="Emphatically" sets AppliedCharacterStyle to a custom style. This should import into InDesign as long as you have these styles set up. For blocks you would use e.g.

::: {custom-style="Poetry"}
| A Bird came down the Walk---
| He did not know I saw---
:::

Remember you DON’T need to type ::: etc. into the editor, use either a Scrivener Style or Section Type to do this for you, hybrid markdown FTW!

---

@ptram

Not sure I’ve understood: can classes only be used in pure markdown?

As alluded to above, anything can be done using the Hybrid-Markdown approach.

@ptram

And then a replacement rule replacing [CR] [anything] [CR] [{img-screen}] with something like [CR] [div .class img-screen] [the same anything] [/div] in the compiled code?

Yes, this is on roughly the right track, and is what I’ve suggested several times above. BUT replacements are but one tool, you really should try to understand what Styles and Section Layouts can do for you. In one example above I use a Section Type to define the wrapper, then replace ««AB»» with the currect Scrivener placeholders. I know that the great flexibility Scrivener affords makes it difficult to see the wood for the trees sometimes…

@ptram

But do you use images linked in the text, or, as it seems from the linked procedure, only placeholder tags?

Not wanting to put words in @drmajorbob’s mouth but his elegant solution uses placeholders. Now if you supplemented his technique using aliases in the binder then you could at least click the placeholders to see the source image…

@drmajorbob

I don’t want the project to grow to gigabit size

I think your workflow is a great solution, though I just wanted to mention that if one uses Research File Aliases then one can still utilise external images while using the Binder and editor-insertion. This keeps your flexibility in placeholder replacements, keeps the project size down, and lets you manage the images with the powers of the Binder. BUT major caveats are they can break if you need a macOS+Windows workflow or you move across hard disks, so this won’t work for everyone!

[AntoniDol]

@ptram

(Ah, what a dream, Scrivener directly compiling to IDML…)

I join you in your dream…

[drmajorbob]

@ptram

But do you use images linked in the text, or, as it seems from the linked procedure, only placeholder tags?

<$img:externalFolder/fileName> is a placeholder and a link to the external file. My process is spelled out in the Notion whose URL I gave before:

image management

[ptram]

@nontroppo

@ptram

I like this, and would like a way to attach classes to images.

I showed you this a few posts ago. You can add the class, ID and any attributes, either directly in the editor or using custom metadata.

The problem with your solution based on links to Binder > [non-Draft] documents is, in my view, that it is both fragile and complicate. Fragile, because aliases tie a project to a machine (and possibly to a folder, if Mac aliases are still fragile as they were in the past). Complicate, because you have to add layers of information, instead of going straight to the object you want to deal with.

@nontroppo

Now the problem is on the Adobe side, can it import well-formed HTML and use the class information or not?

No, it can’t. There is some ways to manually convert HTML to XML by replacements, but it is more mental exercise that an actual working solution.

@nontroppo

ICML

ICML is a step in the right direction. Issues: (1) there isn’t a direct path to compile ICML from Scrivener; (2) ICML is conceived for snippets, and not for full projects (that one would IDML); (3) ICML would work with InDesign, but not with Publisher (the program that is replacing InDesign in self-publishing and with non-corporate professionals); (4) in any case, there wouldn’t be an easy way to assign a style/class to an image linked in the editor.

@nontroppo

you really should try to understand what Styles and Section Layouts can do for you. In one example above I use a Section Type to define the wrapper, then replace ««AB»» with the currect Scrivener placeholders.

Indeed, I can’t understand how Section Layouts could be used to add images. The documents should be broken into smaller units at each image, and this is not practical. Topic-based writing requires breaking a text into small units, but I’m not sure this could work with frequent images. And I don’t know how this could work with icons in the text.

Unless one decides to separate text from images and only use placeholders. But this still seems to me working with an eye on the text and the other on the images, and feels so much Seventies.

Browsing through a long text without seeing the images would be incredibly tedious. I’ve just released a 1,200-pages manual (soon going to 1,600), and I can’t imagine what would it be, checking it with placeholders and no images. Or, maybe this type of proofing should be done on a compiled PDF, then using the Search function to locate any error found in the generated PDF in the Scrivener project.

@drmajorbob

<$img:externalFolder/fileName> is a placeholder and a link to the external file.

But the image doesn’t appear in the editor, unless I’m misunderstanding how it works.

Paolo

[nontroppo]

@ptram

Fragile, because aliases tie a project to a machine

Mac aliases are actually very robust on a machine, and can easily survive moving files around. Their weakness is moving across machines. But honestly, all file links have problems. I don’t use InDesign but have used Adobe Illustrator for many years for scientific figures. I ended up stopping to use import links as the links were fragile, and Illustrator’s link resolution tool was utterly rubbish. This is a fundamental tension in computing: deal with a file directly or deal with an indirection that can obviously break over time as files move around. One thing Scrivener could do fairly easily is allow conversion to/from an alias, but that is for the wishlist…

@ptram

Complicate, because you have to add layers of information

Complicated is obviously in the eye of the beholder, I think using Scrivener’s full set of tools: custom metadata + placeholders + Section Types is simply using the software effectively. Scrivener gives you the tools, it is up to you to choose how to make best use of them.

@ptram

ICML is a step in the right direction. Issues

ICML is the format Adobe developed for InCopy, that is their route to getting written stuff into InDesign. For your point (4) you can transform Scrivener styles or Section Types directly into ICML styles. But if you don’t want to utilise Pandoc using Scrivener’s post-processing feature then indeed you can’t go that route. That ICML doesn’t work with Affinity is unfortunate, but that is a limitation of their software.

@ptram

documents should be broken into smaller units at each image

This is a standard Scrivener convention, and Scrivenings make it transparent for most editing. But I also said you can add the style and attributes directly to the caption, which means you can write in a single document if you want. Styles would also work for inline icons etc.

---

What you appear to be dreaming of is Scrivener to work directly as a dedicated front-end for InDesign. Scrivener is not a layout program, just as InDesign is not a writing tool. If we want to mix and match tools, the reality is we need to be able to handle the many bridges from one complex format to another. And because we are using computers, that invariably means using a mix of tools like Pandoc and scripting to create those bridges. Scrivener’s compiler allows you to do amazing transformations for external tools, and you can do all sorts of style transformation when combining Scrivener’s compiler. Again, I can write in Scrivener, and get that chunk of text tagged as a margin note, floating figure or whatever for open formats like HTML / LaTeX etc. As I can code, I can transform to whatever I want. This fails for your workflow because you are most comfortable with professional layout tools like InDesign, which cannot import semantic information reliably. This isn’t Scrivener or Pandoc’s fault, but Adobe’s.

I can’t speak for the L&L developers, but I highly doubt Scrivener will ever build an IDML front-end. Just look at the spec: pyidml/docs/idml-7.0-specification.pdf at master · guardian/pyidml · GitHub — 200 pages of detailed app-specific tags that are not a standard because Adobe wants to protect its IP. Why should L&L add a complex bridge to proprietary IDML when Adobe can just change it or remove it when they want.

In summary, if you don’t want to use Scrivener’s features (placeholders or aliases or stlyes or post-processing), then you have probably run out of options (at least this thread hasn’t found what you are looking for). Just compile to RTF and spend time doing the finishing in the Affinity or Adobe domain. And complain to Affinity / Adobe that their apps make it hard to flexibly import semantic information.

[AmberV]

@nontroppo

Mac aliases are actually very robust on a machine, and can easily survive moving files around. Their weakness is moving across machines.

With proper care, they can survive transit from one Mac to another, so long as only Mac technology is used to do so, and so long as both the alias and the target are moved together in the same operation. This is a bit like how dragging binder items between projects, that are interlinked, can break the links if you drag them one by one, but if you drag the whole cluster together, Scrivener can relink everything back together with their new internal IDs in the new project.

What won’t work: cloud sync, FTP, a thumb drive formatted to exFAT or other Win compatible format, SMB file sharing, etc.

Scrivener itself takes things even further, in recognition of the common practical problem of how popular these forms of transit are.

In practice, if one plans their user folder organisation around safe alias usage, or giving Scrivener a chance to heal links whenever switching machines, you should not in practice run into broken links.

I ended up stopping to use import links as the links were fragile, and Illustrator’s link resolution tool was utterly rubbish.

That’s one thing Scrivener does with image links to the disk that should, also with mindfulness of keeping multiple machines similarly organised, result in few cases where links break. But even if they do it’s usually very easy to fix broken images as our fallback is to print the broken path as text. A simple project-wide search and replace can find all broken paths at once.

[ptram]

@nontroppo

What you appear to be dreaming of is Scrivener to work directly as a dedicated front-end for InDesign.

Yes, that’s correct. But is it so unreasonable? All considered, Scrivener is the king of the drafting, idea shaping and writing tools. Writing ends up published in some way. Longer writings usually end up in something like InDesign to be released as a printed book. I feel that Scrivener and page layout programs are two benches in the same workshop.

@nontroppo

compile to RTF and spend time doing the finishing in the Affinity or Adobe domain.

It is, indeed, what I have always done. Shape the book, start writing, until you have to put text and images together. But I would like to be able to stay in Scrivener up to the penultimate step, just before the final makeup. A page layout program shouldn’t enter the scene before that phase.

In any case, once in the page layout program all the bridges are cut on the back. There is no way to return to Scrivener, and reshaping and upgrading there.

InDesign can export its complete documents to IDML. It can export a severely lacking document to RTF (with images embedded, and other features flattened). Scrivener can obviously read RTF files, but at that point one has to rebuild everything. There isn’t a bridge that can be crossed two ways.

ICML is the closest bridge, even if incomplete (as you know, it exchanges snippets, and not whole documents). But it only works in one direction, and can’t be used to go back to Scrivener.

@nontroppo

And complain to Affinity / Adobe that their apps make it hard to flexibly import semantic information.

While Adobe is something that I would like to forget forever, I’m complaining as often as I can with Affinity. In any case, I’m not look someone to blame, just a solution.

Paolo

[nontroppo]

@ptram

Yes, that’s correct. But is it so unreasonable?

It is reasonable . But reasonable and realistic are not always bed fellows. As it currently sits, the number of authors who write but also want to layout and publish is limited. In the market, you have content producers, and then publishers. I do think there is some incentive in improving the bridges, but the strongest incentive, people who sit both in the produced words and how they will look on a page, are definitely in the minority, and markets don’t like minorities.

Now if Affinity approached L&L and said, look we want to beat Adobe across the board and can help to improve your content export workflow so we can layout content better than any other solution, that would be awesome. If I was the Affinity developer I would still be using something like Pandoc and its abstract syntax tree under the hood, but this would be wrapped in a UI overcoat. I think it is the job of the layout program to take the brunt of this work, Scrivener can already output clean semantic output to open source formats like HTML and LaTeX…

@ptram

But it only works in one direction, and can’t be used to go back to Scrivener.

Yes, I think getting semantic content back to Scrivener is not yet possible. But again, Scrivener uses plain text XML and RTF and it would be doable to restructure markdown. But going back to Scrivener seems less important from a layout program (no one will be writing content in the layout tool)…

[ptram]

Am I wrong, if I say that an image, by default, behaves this way?

• If it is narrower than the target page, it only takes the number of points equivalent to its size.

• If it is wider than the target page, it is automatically resized to take the full width of the page.

Paolo

[nontroppo]

This critically depends on the format you are compiling to… For HTML / EPub it will depend on the CSS, for LaTeX it depends on the TeX template used etc.

[ptram]

Going through this thread, and having done some more tries, I think that what I want to do is feasible. I just have to readapt my workflow.

1. Images will be added to the documents in two versions: (a) a linked file, that I will resize as I better prefer, that will just be used as a preview; and (b) the placeholder tag to that file, written shorthand, that will then become the actual image.

2. The image will be assigned a different “label”, depending on how it will have to be treated at compile. It will be sort of applying it a class or a basic object style.

A screenshot, for example, will be (shorthand) something like {img.sw main-screen.tiff}, a detail on the hardware something like {img.hw audio-out.tiff}, and an icon something like {img.icn button.pdf}. The initial “img.xx” will be the class.

3. When compiling, the replacements will work to assign them a real path and format. With a PDF target,

{img.sw main-screen.tiff} will become 
<$img:../Images/main-screen.tiff;w=266>

and {img.hw audio-out.tiff} will become 
<$img:../Images/audio-out.tiff;w=500>

When compiling for ebooks I will want them to be a larger size:

{img.sw main-screen.tiff} will become 
<$img:../Images/main-screen.tiff> <-- (I want these full frame width)

and {img.hw audio-out.tiff} will become 
<$img:../Images/audio-out.tiff;w=800>

4. In all cases, the replacements will take care of removing the linked image I used as a preview. I want it to remain clean while editing, so I think that the string to be found at the start of the replacement string could simply be \W\n\{img, where \W\n will be replaced with nothing.

By the way: to select images should I use the \W (non-word characters) wildcard with a RegEx replacement, or the Scrivener $@ (anything) wildcard will be as good or even better?

Paolo

[ptram]

Speaking of placeholder tags – can an image inserted as a placeholder tag get special effects, like drop shadows? I’m probably looking around for the wrong definition, but I don’t seem to find anything about it.

I guess these are things left to a page layout program. But since LaTeX should be able to do these things, I wonder if this is already available when compiling for PDF.

Also, when compiling for eBooks, maybe this can be added to the compile format somehow?

Paolo

[nontroppo]

Certainly for EPub or any other HTML output like PrinceXML PDFs, you can add CSS styles that would style the image in many ways including shadows. I don’t know how many EBook readers support the CSS for box shadows however, you’d need to look that up (so many different display engines, it makes it hard to keep pace). The good thing with CSS is if a device doesn’t support it it normally degrades nicely.

For LaTeX, this would need customisation of the LaTeX template to use particular packages, probably using something like TiKZ, though this solution may require some automatic search/replace processing of the .tex file that comes from Pandoc before the PDF was generated. Or for Pandoc a Lua filter that could modify image output to LaTeX to do this automatically, but none currently exists that I know of…

Scrivener, as it is not a layout program, does not contain any “special effects” built-in to its image insertion as far as I know at least…

[ptram]

@nontroppo

don’t know how many EBook readers support the CSS for box shadows however

Indeed, I’m not sure I’ve ever seen an ebook with shadowing. I guess that having to be compatible with eink devices dissuades from using this effect.

I think I’m getting more and more aware that I should simplify my image style. I’ve never used image effects just for the pleasure of using them, but for transmitting some sense. But there should be some simpler, more classic, lighter way of doing it.

Recently, I’ve had to work with nearly all-black images, where I had to invent a way to make part of the image illuminated. Graphic effects were helping me in a situation where running white connecting lines would have made them disappear on the paper background, while black or red lines would have made them disappear on the image. A double line (white/black) would have been a mess to deal with.

However, maybe cutting details, and not trying to put them in context; and using circled numbers in the images as a reference; could work equally well, even if without the bold, glossy appearance that I was after.

Paolo

[AmberV]

@ptram

Indeed, I’m not sure I’ve ever seen an ebook with shadowing. I guess that having to be compatible with eink devices dissuades from using this effect.

In theory that shouldn’t be a problem, as eInk can do greyscale quite well, and these days at high resolution, as graphics tend to look good. What is more probably the issue is compatibility. I’ve never tried it though. It’s worth testing in Books, Adobe Digital Editions and Kindle Previewer, as that will cover the vast majority of devices on the market.

That said, I do agree with you in that what a shadow accomplishes can often be done much simpler with a border. I switched from using shadows to borders, and I’ve been happy with the look. A border needn’t be bold, and it’s a lot less processing to get them that way.

@ptram

However, maybe cutting details, and not trying to put them in context; and using circled numbers in the images as a reference; could work equally well, even if without the bold, glossy appearance that I was after.

And that simpler approach will translate better to eInk anyway.