Closed simoncozens closed 1 year ago
when the positions are negative the radius gradients don't seem to impact on the pixels at all.
This is now fixed.
It is visible when layer 1 is positioned, then changing the position of layer 2 will also alter the positions of layer 1.
This is now fixed.
I need to find a way to make the gray instead.
This is now fixed.
How to draw multiple shapes in one layer? (See the current code below. Now multiple shapes are drawn in that layer, but the does not seem to work. Only returning if one is returned.)
I don't understand this. We paint the dot glyph twice, once with the radial gradient for layer 1 and once for the gradient with layer 2. If we want to add a new shape, we do the same process again but with a different dot glyph.
On Jun 6, 2023, at 3:55 PM, Simon Cozens @.***> wrote:
when the positions are negative the radius gradients don't seem to impact on the pixels at all.
This is now fixed.
It is visible when layer 1 is positioned, then changing the position of layer 2 will also alter the positions of layer 1.
This is now fixed.
I need to find a way to make the gray instead.
This is now fixed.
Ok, great. Thanks How to draw multiple shapes in one layer? (See the current code below. Now multiple shapes are drawn in that layer, but the does not seem to work. Only returning if one is returned.)
I don't understand this. We paint the dot glyph twice, once with the radial gradient for layer 1 and once for the gradient with layer 2. If we want to add a new shape, we do the same process again but with a different dot glyph.
There should be two layers, each with a number of shapes (gradients, filled, circles, squares). Here an example sketch. So I guess there should be a layer level inbetween that contains the separate shape layers. This is the part I did not manage to get working in code directly.
The concentric circles in the bottom left of each layer would be the current drawing of circles. This way a user can select a pattern of one layer of top of the pattern of the other layer. If file size permits, there could be a third layer (different from the other two, but similar).
P

— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/pull/4#issuecomment-1578815799, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQPWVU2WAFMDFE43ZODXJ4ZEZANCNFSM6AAAAAAY4MQLZE. You are receiving this because you are subscribed to this thread.
Got it down to 48 seconds for a full build and 1.1Mb binary (was 5Mb) by using sparse masters for the masters where the only difference is the shape of the pixel glyph.
@petrvanblokland, I'm afraid your sketch didn't come through on the GitHub email. You could either paste it into the web interface or send it to me privately.
If I understand, you want the user to have two SHPE sliders so that they can choose multiple shapes on top of each other. If that's the case, we'll need another axis and probably a second pixel glyph. I think I can make that work.
Wow!
On Jun 6, 2023, at 6:23 PM, Simon Cozens @.***> wrote:
Got it down to 48 seconds for a full build and 1.1Mb binary (was 5Mb) by using sparse masters for the masters where the only difference is the shape of the pixel glyph.
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/pull/4#issuecomment-1579082072, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQPWPK4NGAKV5WSJGSLXJ5KPBANCNFSM6AAAAAAY4MQLZE. You are receiving this because you were mentioned.
On Jun 6, 2023, at 6:31 PM, Simon Cozens @.***> wrote:
@petrvanblokland https://github.com/petrvanblokland, I'm afraid your sketch didn't come through on the GitHub email. You could either paste it into the web interface or send it to me privately.
If I understand, you want the user to have two SHPE sliders so that they can choose multiple shapes on top of each other. If that's the case, we'll need another axis and probably a second pixel glyph. I think I can make that work.
No, the SHPE axis is the shape of the pixel. The glyph (of pixels) is the mask for the COLRv1 layers.
The 2 layers contains multiple different color elements, ordered in a grid, of which the current concentric circles is just one. The other elements in my sketch will also be colored with various patterns and opacities. Moving the X and Y of each layer allows to select one of the color shapes (or an area between them). Thinking of it now, we might decide to put them in a row instead of grid, but I guess that the areas between the shapes also can contains interesting patterns to fill the pixel masks with. I can make a better sketch (why color) to show what I mean.
Let's reserver "shape" for the shape of the glyph pixel masks And "element" for the color drawings in the layers.
Using /canvas and [clig] OT-feature on shows the square canvas for users to see how the current pixel clip is located in the whole layer drawing.
P
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/pull/4#issuecomment-1579094514, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQOSSUZ4UC6IBVY3YGTXJ5LOLANCNFSM6AAAAAAY4MQLZE. You are receiving this because you were mentioned.
Here's the image mentioned above
OK, now I understand. For what you are trying to do, I think we need to separate the concepts a little further. I think you need:
1) A pixel glyph (which can have different shapes based on the SHPE axis), which punches a hole in a 2) a pattern layer (which is your "layer1/layer2" image above), which is a grid full of 3) element glyphs, which are each filled by different 4) paint fill effects.
Currently we are skipping from 1 to 4, as we have a pixel which is filled by a radial gradient (and then on top of this is placed another pixel filled by a different radial gradient). It may look like we have a "layer of concentric circles", but we don't; we just have a fill effect on the pixel; that is why the "concentric squares" (bottom right in your image) will have to be constructed quite differently.
The pattern layer can be a glyph, or we can just define it in terms of paints.
So next I am going to need someone (probably you!) to design/draw the element glyphs and tell me which paint effects they should be filled with. Or alternatively, I can make something that looks a bit like your sketch, and we can tweak it.
On Jun 6, 2023, at 9:28 PM, Simon Cozens @.***> wrote:
OK, now I understand. For what you are trying to do, I think we need to separate the concepts a little further. I think you need:
A pixel glyph (which can have different shapes based on the SHPE axis), which punches a hole in a a pattern layer (which is your "layer1/layer2" image above), which is a grid full of element glyphs, which are each filled by different paint fill effects. Currently we are skipping from 1 to 4, as we have a pixel which is filled by a radial gradient (and then on top of this is placed another pixel filled by a different radial gradient). It may look like we have a "layer of concentric circles", but we don't; we just have a fill effect on the pixel; that is why the "concentric squares" (bottom right in your image) will have to be constructed quite differently.
Yes, that sounds like the layering I was looking for. The pattern layer can be a glyph, or we can just define it in terms of paints.
So next I am going to need someone (probably you!) to design/draw the element glyphs and tell me which paint effects they should be filled with.
Or alternatively, I can make something that looks a bit like your sketch, and we can tweak it.
It can be either way, but it probably works best if I can code and sketch at the same time, instead of me making drawings and you trying to catch that into code. Also, I think we can iterate through it together. How about doing it this way: • You make the sketch work, where the other elements can be simple place holders. • Then I can see in your code which part is doing what and then substitute the place holders with new code that draw the elements more in detail. • We can iterate over this, where you can comment on what I did, etc.
P
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/pull/4#issuecomment-1579330490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQLHIAAMDPCPYOF2ATTXJ6AGLANCNFSM6AAAAAAY4MQLZE. You are receiving this because you were mentioned.
Okay, I will document how the COLRv1 paints system works; add some placeholder "element" glyphs to the font; and implement the color layer code.
On Jun 7, 2023, at 10:53 AM, Simon Cozens @.***> wrote:
Okay, I will document how the COLRv1 paints system works; add some placeholder "element" glyphs to the font; and implement the color layer code.
Thank you.
Currently I don't see your commits yet in the repository. Is there a separate or hidden branche?
P
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/pull/4#issuecomment-1580231487, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQKSXBZA63NIIVSC5GLXKA6O7ANCNFSM6AAAAAAY4MQLZE. You are receiving this because you were mentioned.
It's right here in this pull request! (Branch of my fork: https://github.com/simoncozens/TYPETR-Bitcount/tree/colr-refactor )
Got it.
Merged.
Thank you
P
On Jun 7, 2023, at 11:05 AM, Simon Cozens @.***> wrote:
It's right here in this pull request! (Branch of my fork: https://github.com/simoncozens/TYPETR-Bitcount/tree/colr-refactor )
— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/pull/4#issuecomment-1580254295, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQLAYW6MGG3GGQHRD53XKA77FANCNFSM6AAAAAAY4MQLZE. You are receiving this because you were mentioned.
This improves the build process as described in #3. The idea is this:
1) Just build the variable font without any COLR axes. This cuts down on the number of masters and improves the build time. (The full font now builds in ten minutes.) 2) Use paintcompiler to add the COLR axes and paint tree.
This has multiple benefits; the code is smaller and simpler, the number of masters is greatly reduced, and the COLR axes now act more like "keyframes" in an animation sense rather than like masters in a type design sense. In other words they can act as "true independent axes", and new positions along those axes are essentially free.
Because they don't need to be defined as separate masters, I was able to change the default positions of the COLR axes as mentioned in #3 to put the defaults at LR1S=500, LR2S=500. I set the minimum of the -X and -Y axes to -500 and the default to zero, but I am not sure I am getting the behaviour that you want; when the positions are negative the radius gradients don't seem to impact on the pixels at all. But I'll keep looking at that. Now I can get the full build working, I can see the canvas, which is helpful to debug it.