How to handle the various settings for what to include on the pattern output

[joostdecock]

We currently have a few settings that control the output:

• complete: If this is disabled, we don't include title, grain lines, notches and so on. However, the exact interpretation of what's included is up to the designer, which opens the door to inconsistencies
• paperless: If this is enabled, we output a bunch of extra stuff
• fuckTrees (working title for future feature): Enable this to bypass all paper-saving measures, such as not printing a rectangle entirely, or not doubling pattern parts for facing/lining halves.

I was wondering if it would perhaps be better to bundle all of these (and future) what should be rendered settings in one bit mask setting.
For example something like:

Bit	Effect
0	Enables rendering of notches , buttons, snaps, buttonholes, ... (functional snippets)
1	Enables rendering of logos (decorative snippets)
2	Enables rendering of grainlines/cutonfold
3	Enables rendering of titles
4	Enables rendering of the scalebox
5	Enables fuckTrees mode
6	Enables rendering of the paperless grid
7	Enables rendering of the paperless dimensions

This is just an idea, we can of course change what the various bits toggle, or divide things differently.
I just feel that packing this all into a output setting with check boxes will be more intuitive for the user.
And it allows us to control the output at render time without the pattern designer having to check for paperless or complete settings.

Might be hard to fit this is as a non-breaking change though 🤔

[eriese]

Into it. I also think we need one that enables rendering of the toolbar buttons in the printing and cutting layout views. pattern designers won't have to take it into account, but on the client side, users should be able to toggle that one.

I think it doesn't have to be a breaking breaking change because most of this stuff is macros, so designs shouldn't need to be changed in any manner for core to know what should and shouldn't be rendered. But it'll enable the establishment of clearer norms around what 'complete' and 'paperless' do, and we can progressively update designs to better follow those norms

[joostdecock]

You can add your toolbar toggle today as far as I'm concerned.
It's local state in the UI, much like Xray for example. So go ahead if you want.

[BenJamesBen]

• Ignoring how it would be implemented or how the UI might look, I would like the capability of even more granular control over what individual elements are displayed. A toggle for notches, a toggle for buttons, a toggle for buttonholes, etc.
• There would be a way to group the elements, for example "snippets" for all snippets or "paperless" for the grid and dimensions. And groups could include other groups.
• There could be official groups like "complete" and "paperless", with official functionality.
• The back-backend implementation could use bits, but for the front end an implementation that used string names would be easier to understand.
• Perhaps the Pattern could maintain its own array or set of elementsToRender?

(Specifically, one of the elements I would like to be able to toggle on/off is points and point names, for new design/debugging purposes.)

[joostdecock]

I'm not married to the bit mask idea. I care more about how it would work than how it's implemented.

I think your all-the-granularity approach makes sense. It's perhaps a lot but then again it's kinda what we do.
I feel that perhaps rather keeping a list of things people should be able to toggle on/off, we might want to allow such toggles to register.

Like plugin-notches could register a toggle to show/hide the notches, and say hey, group me under snippets.
And then plugin-buttons could register a toggle to show/hide buttons, one for buttonholes, one for snaps, and say hey, group me under snippets.
And plugin-logo could register a toggle to show/hide the logo.
And so on.

If we implement some sort of system for plugins to register these toggles like this, then we have a mechanism that we can extend with the granularity we like.

I like this idea, and I might come up with some proposal.

As for names of points to debug, we can certainly add that. Keep in mind that in the meanwhile, you can already get the point name if you click on it (if Xray is enabled)