Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

shapes: Use decoration style #541

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Conversation

johannes-wolf
Copy link
Member

@johannes-wolf johannes-wolf commented Mar 30, 2024

Implements #465.

This PR is a WIP implementation on how to implement decorations as style option for all (but grid and mark) elements.

The idea:

  • The context has a decorations dictionary that can be modified to add custom decorations.
    This allows for a function like register-decoration(...) for plug-ins (same plan as with custom marks; not added yet).
  • The user can either use a decoration name (dict) or pass a function to decoration: .. for elements. Element paths get decorated before adding marks, which allows for styled paths to have marks.
  • You can still use decoration-functions via composition.
  • You can apply multiple decorations in sequence
  • Decorations can be applied on a subsection of a path (start, end)
  • This API will replace the current decoration lib
  • It works without destroying marks

Demo of the wave and linearize modifiers:
grafik

Copy link
Member

@fenjalien fenjalien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll need to write a specification of what a decoration function should expect to receive and what it is expected to return.

What do you think of blocking this until we work on modifiers?

src/draw/shapes.typ Outdated Show resolved Hide resolved
@johannes-wolf
Copy link
Member Author

johannes-wolf commented Apr 7, 2024

@fenjalien I've updated the API. This new modifier implementation is meant to completely replace the decortaions.path library and move path modifiers to cetz core.
I think decoration: should be named modifier:.

The PR is still very WIP but should give a first idea. It is a better implementation than what decorations.path currently provides.

I wrote some information to the connected issue.

@johannes-wolf
Copy link
Member Author

Rebased.
How do we want to proceed with this?
I am open to change the name from modifier to something else, although I prefer modifier or decoration over show-rule, as it is more explanatory.

If we merge this, we can implement marks on top of this. I prefer not touching the mark implementation before we agree on a modifier/decoration implementation.

If we want to support outputting extra geometry from modifiers, we should discuss how to do that. The current interface does not allow this. To add support, the apply-* function must know if the returned drawable is part of a continuous path or if it is some “standalone” shape.

@fenjalien
Copy link
Member

I'm happy to continue using modifier, but I think using show-* would help to draw a parallel to Typst's show rules. I don't like decoration.

I would really like to get on with this but I want to get the docs website up properly and I'm struggling to find time for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants