Evgeny Stambulchik

Documenting is not a big deal by itself, but making it an official schema description implies promises of maintaining compatibility etc. The .pdfpc format is not intended to be used...

@MJimitater It seems to me you read neither the original post nor my reply...

> It looks like with the most recent release of Marp, support for PDF annotations was added (https://github.com/marp-team/marp-vscode/releases/tag/v1.3.0), so that's mostly solved my workflow. Good to know. > It may...

@zhangchuck Is #610 what you want?

@AndreasBilke my idea was to keep this file under the main pdfpc repository, but copy to github.io with the versioned path (like https://pdfpc.github.io/schema/pdfpc/2) upon release of new pdfpc versions if...

> Then you can reference them with "Latest release"/schema. In that case, there would be no easy way to find a specific older version of the schema. I really doubt...

It seems we're talking about different things. What concerns me is the "$id" key, whose value must be a string uniquely identifying a given schema version. Almost universally (though not...

Right, that seems the only reasonable way. We also need to setup the "extensionless" URL's to be redirected to the respective .json file, I suppose it's possible with github.io.

@bytinbit It seems you create the obsolete style .pdfpc files, not the current JSON-based ones. In fact, I'd rather augment the exported PDF file with native PDF annotations, which pdfpc...

Well, I'm not sure it is necessary. Typically, the latest stable version is available on the latest Debian-based (and probably others) live ISO's, e.g., Ubuntu-21.10. From there, just `sudo apt-get...