blesmol / pfscf Goto Github PK

pfscf batch create <template> <output> to create a csv file with all content IDs available in the provided template.

pfscf batch fill <template> <csv file> <output dir>?

Print a warning in case the blank chronicle provided by the user has a different aspect ratio than what is defined in the template config. Even if the aspect ratio is identical there might still be errors, but it can definitely help when determining the root cause of misplaced entries in a filled chronicle.

• Alpha
• Fill pattern
• Border
• Border pattern

Text is currently auto-shrinked if the text is too width for the textCell. The text should also be shrunk if it is too high for the textCell.

If a text is too long to fit into a given textCell, then automatically reduce the font size until it fits. Should be switchable per content in a template.

Currently the validation order of the template is indeterministic. This is unfortunate, because if there is an error in a parent template, it might be reported as validation error for a child template.

So the order should be made deterministic.

It should be possible to define scenario-specific values to support things like, e.g. conveniently set checkboxes in text.

This should also be configurable, and it should "inherit" the generic chronicle configuration.

Users may come up with blank chronicles that still have some margins on at least one of the sides, making it hard to correctly fill out a chronicle. Thus provide additional command line parameters for fill and batch fill that allow to fine-tune this for the concrete input chronicle provided by the user.

This would allow GMs to give out chronicles that cannot easily be changed by other people.
Password should either be random or user-provided.

Permissions should also include that no annotations can be made to the file. Printing needs to still be possible, of course.

Example "remove-boon=1,3"

1. Simplification
2. Alignment with other naming

Currently the order of param entries in batch files created via pfscf batch create is based on lexical sorting. Instead allow other sorting, e.g. from list in template config, to have less searching.

Because sometimes its so much easier to type pfsct t l instead of pfsct template list

Files where the filename starts with a dot (".foo.yml") are considered hidden by some OSes and should be ignored,

The chronicle sheets position on the page itself changes from adventure to adventure.

This leads to a wrong positioning of the labels.
I.e. In #1-06 the player & character name overlaps with the scenario title itself.

Online sessions often share GoogleDocs documents in which the players can then report things like their characters name, society ID and the like. It would be good to have some command similar to pfscf batch create, only that instead of creating a basic csv file it already imports relevant data from the Google Docs document.

Of course this will require certain assumptions about the structure of the document, which yet have to be determined. Or having separate easy-to-understand config files that describe the relevant structure of these documents.

Would allow people to get a glimpse on what some concrete template can do.

Open questions:

• How to deal with missing example texts
• How to deal with overlapping or mutually exclusive entries

Instead of using the dir where the pfsct executable is located, use the OS-specific app dir for this, e.g. %APPDATA/pfsct on windows. This should ensure that the coming auto-update mechanism can update the required files, even if the executable is located elsewhere. It would also allow to not include the templates at all in the release, but instead download them on first use.

Seems that backup files are currently also read, although only files with file extension .yml should be considered. This needs to be fixed.

Under the assumption that they have a more or less static structure as well. Perhaps parts of the PFS2 config can be reused with little effort.

Have a config file, perhaps in yaml format, that holds a description of valid input parameters:

• id
• type
• coordinates
• font+size

This would allow to change what can be put on the chronicles without having to modify the program

Seems page extraction is no longer working as expected if updating, neither in git bash nor powershell.

Wait with update of pdfcpu until this is fixed.

A proposal was made that it would be good to have functionality that would automatically calculate the gold a character receives based on the characters level and the number of treasure bundles that the character received.

This should not replace the current option to provide a gold value directly, but merely be an alternative option. It would require that also the char level is provided, which is currently not done, as it does not appear anywhere on the chronicle sheets. And it would also require to keep the table somehow in the game-specific template.

Required template fields without valid entries should result in a meaningful error

Provided fields that are not used by the current template type should result in warnings

Action 'template search' should take one or more keywords and search the ids and descriptions of all available templates.

Having a separate presets section has advantages and disadvantages. It would probably be easier to maintain if the presets section is removed altogether and replaced with a new content type preset instead.

To keep track as user on which template inherits which one and also to bring some more structure into a list of templates, the output of pfscf template list should be presented in a tree-style fashion.

Below each template should be an indented section where all templates are listed that inherit that template.

For some use-cases it makes sense if content entries can have (named or unnamed) subcontent entries. Everything else would be just stupid workarounds.

Some possible use-case examples that do not necessarily resemble working content:

Example 1

Usage: tier=high

tier:
  type: choice
  subcontent:
    low:
      type: crossSomethingOut
      x1: ...
    high:
      type: crossSomethingOut
      x1: ...

Example 2

Usage: gm_initials=MJ (relevant, e.g., for Starfinder)

gm_initials:
  type: multivalue
  subcontent:
    - type: textCell
       x1: ...
    - type: texCell
      x1: ...

• Basic yaml explanation
• Content types
• Presets
• Inheritance rules

Currently only the binary and the LICENSE file are included. For a proper release also config files need to be included.

Could be that it just does not make sense to have these separate, as validation can (and must) happen after resolving entries has happened.

Go away from the "latest-and-greatest" approach, use well-defined versions

Currently there is no check, but if something wrong is provided, then no good will come from that. As I also do not support including own fonts, a check or at least a warning should be included.

Should, amongst others, display examples for each described field and its type

Currently they are not very userfriendly wrt finding out what is going wrong in case of an error within a template yaml file.

Allow to configure a path for blank chronicles. In that path, look whether a file exists with the same filename as the required template, e.g. "pfs2.s1-15.pdf". If so and if nothing else was specified on the command line, use that file automatically.

Currently there is an (outdated) documentation on how to write your own templates. Which is good and necessary, if it wasn't outdated. But ok, we will come to this.

But there should be a separate documentation only targeting the scenario where a user wants to adapt an existing chronicle template to a new scenario. The user probably doesn't need to know about the complete format. Only like "create file there, enter this, check whether everything fits, if not that is how you correct things".

Add better explanation on where to download this, i.e. add hint to "Assets" section (and check whether that section can be directly referrenced)

At the moment I assume that sooner or later working on the chronicle configs will become more complicated if the canvas concept continues to be used as is.

Possible new approach:

• Add new section "canvas" to templates, besides "presets", "contents", etc.
• Entries in "canvas" section are named and have a subcanvas relation. Not necessarily expressed in the yaml structure, but perhaps similar to the "Inherit" entry.
• Content entries get an additional field "canvas" that denotes a canvas ID
• To modify a canvas in a template that inherits from one of the main templates: This is either done via presets as before, or canvases with the name ID in the child take precedence during inheritance

Provide builds for win, mac, linux for tagged releases.

Support an auto-update mechanism for the template file(s) so that changes and improvements to the chronicle templates or scenario-specific settings automatically reach the users.

For this, the program would try to reach a well-defined URL (e.g. here on github) that holds information on the latest templates. In case the local program finds newer information, it could automatically download the new templates and store on the local machine. This should be made transparent to users and configurable so that users can switch this off. Or only be triggered by a special command, e.g. pfsct template update or the like.

The program itself won't get an auto-update mechanism now. Maybe using the same mechanism it could check the centrally available version and output a notification if a new version is available.