[kroki-fetch-diagram] generated-file-name parameter not used

see #47 for my setup

My test presentation.adoc sets the imagesdir and use generated-file-name parameter to have all images with human readable names:

ifndef::imagesdir[:imagesdir: ./images]

== UML class diagram test with kroki
[plantuml, "diagram-classes", svg]
....
class BlockProcessor
class DiagramBlock
class DitaaBlock
class PlantUmlBlock

BlockProcessor <|-- DiagramBlock
DiagramBlock <|-- DitaaBlock
DiagramBlock <|-- PlantUmlBlock
....

It fetches the diagram and writes to images/210a0ebf2a7bb40669c4e3c895b2c9396f048327.svg instead of images/diagram-classes.svg like ascidoctor-diagram does.

It would be good to support the mandatory diagram parameters from asciidoctor-diagram.

[Mogztter]

To achieve that goal, I propose using the diagram name specified on the block as the filename prefix in place of diag (e.g., diagram-name-cf699e6a13a1976b55764d80b6f9d508.png).

That’s a good idea! I wonder if it exists a better (shorter) hashing algorithm to make the filename more human-friendly? I did a quick search but I couldn’t find a good alternative.

That makes the filename recognizable while still including the hash to serve as the cache key and to prevent filename conflicts. wdyt?

I agree, let’s do that 👍🏻

[mojavelinux]

The linked PR is closed, however this issue is still open. In my trials (using the RubyGem), it appears that the custom / human-readable name is still ignored (https://github.com/Mogztter/asciidoctor-kroki/blob/master/ruby/lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb#L291). Is that accurate? If so, is the plan still to support the custom name, or is there a reason for always using the auto-generated name?

I’d be glad to help get this resolved.