%filename() not resolved for export diagram when used in title

[ThirtySomething]

Hello,

I'm using the function %filename() in the title tag. When I'm exporting the diagram, the title tag is used to get the filename. Unfortunately the function %filename() is not resolved and the name of the exported diagram will be %filename().svg.

File test.puml

@startuml title %filename() A --> B B --> C A --> C @enduml

Calling the export function this results in the filename %filename().svg instead of the expected filename test.svg.

Info of VSCode: Version: 1.56.2 (user setup) Commit: 054a9295330880ed74ceaedda236253b4f39a335 Date: 2021-05-12T17:13:13.157Z Electron: 12.0.4 Chrome: 89.0.4389.114 Node.js: 14.16.0 V8: 8.9.255.24-electron.0 OS: Windows_NT x64 10.0.19042

Version of plantuml plugin: v2.14.5

Edit: Maybe this happens also to some other builtin preprocessor functions of plantuml. For more details see here.

[qjebbs]

The extension doesn't (or can't?) call the preprocessor, and won't able to know the processing results. So don't use any builtin functions [%] in title or diagram names

[ThirtySomething]

I understand that the extension is not able to call the preprocessor. I got a draft look at the code. As I understand and the title tag is not set, the extension will take the real filename. So I was thinking about functions like %dirpath() or %filename() could be replaced with the original information? Seems to be possible. Passing the filename including the full path information. When it comes to the title.Deal function, check and replace the keywords with the passed information. It's seems to be possible by extending the list of regular expressions or with a simple string replace at the end of the title.Deal function. I assume doing this way, a lot of the builtin functions could be 'enabled' like

• Any date/time function as long as TypeScript offers a way to get this information
• All filename/pathname because the extension already get this information somehow
• The string operations are looking also possible to be interpreted
• In case of an API to the operating system, reading of environment variables seems to be possible

Others of the builtin functions will obviously not work or does not make any sense at the moment like

• Dealing with true/false values
• Working with variables
• Color related builtins
• Claiming version information

The question is the effort for a kind of preprocessor for the extension. Maybe it's possible with a manageable effort.

Edit: As alternative a kind of processor is also possible to perform on several places the replacement. Maybe not only for the title this kind of processing is relevant.

[chipbite]

This may be an attempt at a workaround since the extension behavior differs from plantuml behavior, and uses the title element to set the output filename. I have reported this a bug: #438. I think it would be better if the plugin behaved in accordance with plantuml.

[arnaudroques]

The extension doesn't (or can't?) call the preprocessor, and won't able to know the processing results. So don't use any builtin functions [%] in title or diagram names

I'm quite late here, but I think I can help. The real issue is that plantuml does not expose the title of a diagram. I guess that if the core library would expose the actual title, it would give a way to fix this issue.

Am I right ?

@qjebbs If I am, then we could talk about the easiest way for you to get this title. For example, what about using a non-standard HTTP header X-Title where we would put the title ?