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

view: Cycle through multiple fg colours if supplied #42

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

wezm
Copy link
Contributor

@wezm wezm commented Oct 25, 2024

Closes #41

@n8willis had a go at implementing #41 here's some sample output:

allsorts view -f ../prince/tests/data/fonts/morx/Zapfino.ttf -t 'Zapfino'\!'' -s LATN --features kern,mark,mkmk,liga --fg-colour ff0000aa --fg-colour 00ff00aa --fg-colour 0000ffaa

Zapfino

allsorts view -f /home/wmoore/Downloads/lanna-export-pdf-issue/LN_TILOK_V6_05.woff -s thai -t 'เวรญชฯกณฑ' --features kern,mark,mkmk,liga --fg-colour ff0000aa --fg-colour 00ff00aa --fg-colour 0000ffaa

master

Note: there's an invisible/zero-width glyph in this one, which is why it skips the second use of blue.

@n8willis
Copy link

Looks great! Thanks for taking a crack at this.

On the syntax, would there be something that prevents using a comma-separated list, à la --fg-colour ff0000aa,00ff00aa,0000ffaa ?

Thinking about it overnight, I believe that counting the invisibles/spaces as part of the target sequence (as you've done) is the only approach that makes sense. It doesn't do any harm for those who don't care, and if someone wants to see that an invisible or space has changed or moved between two calls with different options or different fonts, it's valuable.

@n8willis
Copy link

Actually, another question. Is the most desirable model that the color list applies to the input sequence or to the output sequence — i.e., after reordering might have occurred?

I was thinking output originally; perhaps that's the only one that makes sense here. The wrinkle is that you provide the input sequence, but arguably you don't know if the same number of glyphs will be in the output, if you're doing it to debug the font, in order to specify the same number/order of colors. That might be overthinking it though....

@wezm
Copy link
Contributor Author

wezm commented Oct 28, 2024

Actually, another question. Is the most desirable model that the color list applies to the input sequence or to the output sequence — i.e., after reordering might have occurred?

I think colouring based on input sequence would be quite difficult with the current code due to the need for yeslogic/allsorts#31

The wrinkle is that you provide the input sequence, but arguably you don't know if the same number of glyphs will be in the output, if you're doing it to debug the font, in order to specify the same number/order of colors.

The way I implemented it, it will cycle through the colours supplied, looping around if necessary. So you can supply as many colours as you want and it will always work.

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

Successfully merging this pull request may close these issues.

view: multiple colours
2 participants