thecomamba / loretex Goto Github PK

They then contain a label. These entities could even contain sub-history items. This might be useful for important events lasting several days.

Maybe we need a new chronologies type for this feature.

A list which stores "day of year" and associated "average temperature". If the current day is globally set, we can linearly interpolate between the points to display the expected current temperature.

Now that descriptors can be sub-entities, they could for example be secret, have their own association, their own ageFactor, etc.

Repro Steps:
1.: Create a new entity.
2.: Add a birth event by calling the \born{} command.
3.: Give the entity a species that exists and ages.
4.: Add a descriptor with a labeled subparagrah.

We could point to either (anonymous) history items that must contain a year and may or may not contain a day, or we could use a label of a historyItem entity (once they're implemented).

Relevant for history entries.

Adding a secret history item and then a non secret history item, and then printing without secrets, the date is not shown.

Prerequisite: #32

Python can generate PDF documents as well. This would create another channel for users to access the functionality.

In that case the repo should probably be split up into LoreTex, LorePy, and a subrepo containing the rust code.

Columns "parent", "child", "relationship"

Lua then becomes a thin layer merely calling the rust library.

If the answer to #53 is yes, we probably do not need any translations.

At the moment the captions for entities which sort them by location are generated from the location's shortnames. It would be nice to have some link to the location. One solution would be to use nameref commands instead of the shortname in the caption, but then the shortname in the optional argument of the caption (otherwise the table of contents contains links in links, which screws it up.)

Another solution would be to add a "Compare \nameref{some-location}." between header and entity.

Both solutions only make much sense if the locations are primary refs, and not only mentioned.

Something like
\subpagraph[short]{long} \label{sub}
should work.

And then we also need an optional shortname argument for setDescriptor.

Using the information of months we can print out a table with an entry for every day (or maybe some smarter version of a calendar).

We could also define a new chronologies type named "holidays", which are automatically added to their affiliated calendars.

https://github.com/typst/typst

This would significantly lower the entry-bar for new users, especially those without a programming background.

All types would need to be defined by the user.

I thought every entity has a label?

This might be relevant for rivers, which are often the border between two countries. Should they be part of both?

Is that already the case? Write a test!

A little code for this feature already exists in the file dictionary.lua, from the time before feature branches and pull requests.

It would nice to give RpgTex a table input and have it print that table in a user defined version. For example, you can give it a dictionary for a fictional language containing the columns "English", "Grey Elvish", "Elvish Spelling" and "Pronounciation", and then make it print the table in that column order, with rows sorted alphanumerically by the "English" column, and then print it again with only the columns "Grey Elvish" and "English", rows sorted by the (now) first column.

Currently, affiliated entities are sorted alphanumerically. This is probably useful for most cases, but not all. Take, for example, a dynasty that lists all its rulers. Here I'd like chronological sorting (Henry VIII before Elizabeth II).

One possible solution is to add a protected descriptor "sorting" to entities, which contains either an empty string or another protected descriptor, by which affiliated entities are sorted. One drwaback is that currently not all contents of protected descriptors are sortable. For example, sorting by the role of an affiliation member is not directly possible with this setup.

More thoughts required!

Analogous to test code.

grep for LogError and DebugPrint, needs to become a table, otherwise we try to concat strings with tables.

Repro Steps:

1. Create a year format with a year offset.
2. Create an entity with some birth year.
3. Add a second entity as the parent of the first.
4. Make the second entity primary and print it.
5. The birthyear printed with the first entity is not displayed correctly.

This makes debugging in tex much easier, because any undefined command in any descriptor will otherwise just lead to the error message "command automatedChapters is unknown".

Managing around a thousand entities is quite annoying when they are sorted in files. I often find myself using grep to find out what file a specific entity is defined in.
It would be much cooler to store all my entities in a database, with a small GUI to access it. It should contain a search field, and maybe some checkboxes generated from the content (e.g. "show me only entities of type npc").

RpgTex already exists as a template for a DnD5e inspired look and feel: https://github.com/rpgtex

Repo is already renamed, but the former name still persists through the code.

Print warning if an entity has no location set.
Setting location explicitly to empty string is ok, because some top-level entities have no location.

Compare https://github.com/iced-rs/iced_aw#modal

Ideally this should contain at least one usage of every TexApi function.
Maybe we can add the usage measurement currently only used in the tests to the Debug namespace and thus check which Api functions are not yet used.

This document should also be compiled by the pipeline scripts.

Using
texio.write_nl( message )

Or could we just print one chapter per type?
Then we could remove the need to declare types beforehand - they are just deduced from the types that appear in entities.

To \birth, \death and \ignore.
Currently we have the latex command \birthof, which has a different casing than the protected descriptor birthOf.