Allow multiple dates in cvEntry

[LeWimbes]

This pull request introduces support for multiple dates for a single position. The feature reduces redundancy and saves space for recurring roles such as internships and teaching assistant positions.
To achieve this, a cvEntry is split into two columns: the first column contains the logo, title, society, description, and tags, while the second column displays the location and date(s) only.

[yunanwg]

Actually I thought of having this kind of feature, but put it on hold for complexity reason.

To me, it will be superb to have one entry with multiple dates; but that ideally if we have also have separate entryDescriptions. Imagine working as an intern first and then full-time will definitely have different scope and missions.

I haven't got the occasion to think this over, but definitely open to your idea!

[LeWimbes]

I absolutely agree that this would be an amazing feature! In your example, though, we wouldn’t just need a different description; we’d likely also need a different title, and in the "worst" case, even the location could be different, with only the society remaining the same.

At the moment, I’m not entirely sure how to implement something like this (I only started using typst a few days ago). If I come up with a solution, I’ll happily open another PR. For now, though, I believe this lies outside the scope of this current PR.

[yunanwg]

I understand. Will take a look on this in the following days to see if I can come up with a better solution; otherwise I will accept this PR as it is.

[LeWimbes]

I gave it some thought, and so far the best I can come up with is an array of dictionaries:

#let cvEntryComplex(
  society: "Society",
  location: "Location",
  logo: "",
  tags: (),
  positions: ((title: "Title", date: "Date(s)", description: "Description")),
  metadata: metadata,
  awesomeColors: awesomeColors,
) = {
  [TODO]
}

As I mentioned earlier, it might even make sense to include the location in this dictionary. (Maybe even the tags?)
One thing that's definitely a must as far as I can see is that display_entry_society_first must be true for any of this to work.

[yunanwg]

So I've added a new function cvEntryContinued, which is basically a replicate of cvEntry, but with logo, and A line ripped off. Here is the visual with and without logo.

Do you think it's a viable approach?

[yunanwg]

I have the impression that my implementation might not be exactly what you had in mind. Do tell me what you think and how we can better consolidate these less-frequent features!

[LeWimbes]

Actually, I like your approach, since users don't have to construct some complex array/dictionary monster.
The only thing that doesn't look so great to me is having that gap on the left where the logo is for the first position. On the other hand, if the position is simply placed below the logo, some space is wasted:

I tried to get rid of the big gap between the society and the first title, but at least v(-beforeEntrySkip) didn't do the trick.

[LeWimbes]

Actually, I just noticed a minor issue with this modular setup: since it's several different tables, if the dates are of different lengths, the descriptions don't line up nicely:

[yunanwg]

Actually, I like your approach, since users don't have to construct some complex array/dictionary monster. The only thing that doesn't look so great to me is having that gap on the left where the logo is for the first position. On the other hand, if the position is simply placed below the logo, some space is wasted:

I tried to get rid of the big gap between the society and the first title, but at least v(-beforeEntrySkip) didn't do the trick.

Understandable, as I noticed this too. It can be an easy fix, just put logo in the level of A line instead against A and B lines; my concern however is that this will be a breaking change for existing users as it will modify the size and the placement of the logo.

Actually, I just noticed a minor issue with this modular setup: since it's several different tables, if the dates are of different lengths, the descriptions don't line up nicely:

This one can be fixed too by persisting the length of the B table, currently it was set as 1fr if I am not wrong.

[LeWimbes]

Understandable, as I noticed this too. It can be an easy fix, just put logo in the level of A line instead against A and B lines; my concern however is that this will be a breaking change for existing users as it will modify the size and the placement of the logo.

I'm not entirely sure what you meant by that, but I believe I circumvented the issue by adding v(-10pt) at the end of cvEntryStart.

This one can be fixed too by persisting the length of the B table, currently it was set as 1fr if I am not wrong.

Instead of fixing the width of the first column, I opted to constrain the second column since dates tend to have a more predictable length. While I only speak English among English, Chinese, French, and Italian, I tried to find the longest possible date formats across these languages (with the help of LLMs).
Since fixing a single width for all languages would result in wasted space for some, I introduced a dateWidth function that determines the maximum width I could come up with per language.
Please feel free to let me know of mistakes or adjust it yourself if you have better insights into these languages!

[yunanwg]

I'm not entirely sure what you meant by that, but I believe I circumvented the issue by adding v(-10pt) at the end of cvEntryStart.

I think that the introduction of cvEntryStart solves my concern -- let me rephrase that -- my concern was that changing the way how logos and titles are organized would bring breaking changes for current users; but since we don't change the cvEntry function I think it's good.

Appreciated the fix of the column length for dates! I will review the changes right away.