The designer of this FontStruction has chosen not to make it available for download from this website by choosing an “All Rights Reserved" license.
Please respect their decision and desist from requesting license changes in the comments.
If you would like to use the FontStruction for a specific project, you may be able to contact the designer directly about obtaining a license.
Testing the new square connector bricks with a simple outline font.
I ran into an anomaly where one of the new bricks glitches out after saving. Easy to fix using other bricks, but I'm leaving it here to show some interesting effects the glitch is producing.
1. It looks like there is a boolean operation going on with it. Something we've been asking for for a while.
2. When grabbing the brick, it highlights an area of about 9 grid spaces, as if it were a group of bricks connected together. Another feature that has been requested for a while.
Anyways, the brick in question is the last one listed on the Bricks:Connect panel
not kewl... probably a easy fix for Rob too :)
It haapened to me too... I tried building a C with it, it got corrupted...
Aside from the wonky geometry, this unexpected brick appears to be following the same default behavior for all brick definitions – and the standard convention for most vector graphics software.
We have bricks (e.g. the unit circles that contain smaller circles “cut” out of them) that also follow this principle. Regions are defined as filled or unfilled based on counting the number of overlapping regions. It’s a kind of boolean.
But it’s not a new boolean operation per se – criss-crossing sides of an overlapping non-convex shape would create a spider work of checkered regions just like this (“filled” or “empty” depending on how many lines cross).
This botched brick is still quite interesting. It demonstrates the present possibility for individual bricks to contain geometric data extending beyond one grid space.
For instance, we could have macrobricks (“blocks,” say) that occupy 2x2 or 3x3 regions. Without utilizing filters or other obscure techniques (such as brick patching) to realize larger scale curves than presently possible.
FontStruct has had a convention so far to restrict the brick space to 1x1 units. However this is clearly a design decision and not a restriction of the codebase itself. This approach makes sense regarding simplicity and extensibility.
How would compositing bricks and blocks work, for instance? It’s not obvious or particularly elegant.
Other than add/stacking, booleans applied between bricks are still yet to be realized to my knowledge. Try compositing the glitched brick, forcing overlap with adjacent bricks in the composite, and you will see that overlapping regions still have basic stacking – no inter-brick cut outs.
Grouped bricks officially exist within the constraints of stacking and compositing.
Nudge-stacking is another form of grouping bricks. This is where each brick in a stack has individually addressable nudge vectors. I call it “brick patching,” and it is achievable through a glitch very similar to the original approach to brick stacking.
It is a super powerful technique that I will soon get around to demonstrating publicly. Several intrepid fontstructors, perennial pioneers such as yourself, have constructed complex curves through clever combinations of bricks. Brick patching remarkably amplifies this approach and unlocks vast and uncharted diversities of form in the minimal grid. I’ve pictured a relatively simple patch in a font I’ve been structing.
Thanks for sharing, Gene – always, always lovely to see dig into the matrix of gridbreaking wonders with your contributions here. 😊
It remains kind of weird though, when opened in the editor and after making a simple composite brick out of it all shapes overlap, resulting in a closed shape (brick). I also put the standard brick along with it to compare all the results later. So next thing I did was saving the font and refreshing the editor. Uppon reloading the editor the composite bricks remained intact whereas the standard brick got glitched (as expected). Now what I dont get is, viewed from the gallery or font preview the bricks remain glitched no matter what, even with the seemingly intact composites.
@WL Welcome back!
@STF There is that same C I tried to build...
By all rights, I was not entirely correct – and am retracting my statement that the overlapping regions are simply being filled by a standard approach to compound paths of zig-zagging overlaps.
I think that’s part of what’s happening. But there’s something more bizarre going on with this bricks definition, resulting also in zoom-dependant variable display in the fontstructor (unedited screenshot):
@STF – regarding the closed shape once downloaded, the Fontmortar has the ability to simplify overlapping shapes, retaining just their outline.
it does basically the same as most vector and font software also allowing, right? Connecting all neighboring nodes in any remaining open segment an that way closing the contours? Or is it actually doing more than that?
Ok, now I’m speculating well beyond my knowledge regarding how this bug occurred. The fact that manipulating the zoom slider gave variable geometric and coloring results (even the preview widget can output these intermittent gradients) makes me think something more complicated was going on and the software was doing its best to close the shape.
Maybe the data type being considered for the wonky nodes was mismatched and a monad managed to pass RGBa and position data from whatever was being fed into it.
Like you said, Meek’s on the case!
@geneus and @will.i.ૐ – great to see you both on FontStruct again. I will look at this when I get time (very busy right now). It looks like just a corrupt brick definition.
Thanks, all! Its good to know I wasn’t the only one experiencing the glitch. My own tests confirm functional compositing and stacking of the anomaly.
@meek Thanks for looking into this.
@Will Leave it up to you to discover vector gradients in Fontstruct! I would have thought vectors with alpha channels are beyond the scope of FS. That ’s’ you posted is ridicuballs, btw.
This glitch made me think boolean operations and individualized local brick filters beyond a scale of 2 are closer to being possible since it can be done by accident.
I always pictured the boolean operations happening via a 2nd layer placed over the existing fontstruction. This layer would be able to turn on or off, and the boolean function would be a post-process that occurs during font export. The top layer would contain any brick that would subtract from the brick below it. If we wanted to hide bricks from publication, we would simply duplicate the content on the bottom layer to the top.
If we had horizontal and vertical Brick Scale filters on a local, individualized grid space, instead of global, this would enable actual-sized brick grouping of composites up to an area of 4x4 bricks if the scale was increased to 4 instead of 2.
Crossing my fingers for these things! :-)
@WL Still wondering how you made that S??
@meek I predict that Geneus1 will comment "@meek Thanks for the Top Pick!" when he enters this page...
@Se7enty-Se7en Your prediction of my comment is wrong and I will prove it by merely quantum jumping into an alternate reality in which meek has a constant awareness of my ongoing gratitude of all that he does. Hold on a sec ... and we are there now. Did you feel that? That. just. happened.
first featured font with brick corrupted?
i noticed the glitch while making a font that looks basically the same as this one tbh
tried to fix it for a while and it didnt work :/
@will.i.ૐ - WHAT THE F̦˦˨̱̊ͥ˧Ʌ̌͏˦ǳ?
Edit and Delete option no longer showing on my comments ;(
@will.i.ૐ - Teach me!!!!! I gots to know ###!!! 731363!3167186378761&#!*^*!^8! 252957898(*! $&*($@(*$&@*$
I be gettin' jiggy wit' it... sorry,
Please sign in to comment.