Hello!  It's been a while, hasn't it?...

The creation of this font is my first real activity on this site after an almost 2.5-year hiatus, as at this point I believe my mental health and schedule finally permit me to return to fontmaking.  I do apologize that I sort of left without much warning, and I further regret to admit that I can't quite confirm I'll be as active as I once was.  I hope I can be, but I don't want to make any promises.

However, for now, I present GS Unicode 3.0!  This font series will utilize composite bricks provided by djnippa with this font, although I'll be sticking to 1:1, 1:2, 1:3, 2:3, and possibly 1:4 slopes to keep things more organized and less laggy, especially as I approach the 65535-character mark.  This will otherwise largely be a continuation of GS Unicode 2.0, meaning it will keep the same width:height ratio, general shapes, and overall "feel" (hopefully).  The decision to make an entirely new font, as opposed to continuing work on the former, was one I'd been wrestling over for the past few months as I contemplated my return.  Ultimately, two major factors influenced my decision.

Firstly, for reasons I won't go into, I wanted a fresh start to my life, and GS Unicode 2.0 was unfortunately a casualty of a past that I otherwise don't want to remember.

Secondly, and more significantly, I wasn't overall happy with the development path that GS Unicode 2.0 was taking.  As the character count mounted, I discovered that the list of things I wanted to change was increasing too, and it was becoming extremely difficult to change a glyph without it affecting others whose geometries were based on it.  I've also wanted to restructure the extremely bloated and largely disorganized Private Use Area for quite a while, which was a similarly daunting task.  Please know that this is not a criticism of the recommendations y'all have given me.  I thoroughly enjoyed all of your creative and imaginative suggestions, and it was actually one of the things I enjoyed most about fontmaking!  However, I don't think it's controversial to suggest that there doesn't need to be a 4096-character space filled with just precomposed Latin-diacritic combinations (there's a reason Unicode stopped doing this after U3.0).

If you made a PUA recommendation on GS Unicode 2.0, I'll get to it here in due time, once I'm more organized and this font is more stable.  You don't need to re-recommend anything here, as I still have access to the GS Unicode 2.0 page and most of the code charts that I've been sent.

Even though, like its predecessors, GS Unicode 3.0 is meant to be a pan-Unicode font, I've only published it with Basic Latin to see what y'all think of it first.  I'm not super happy with some of the curves and angles, especially on 6, 7, 9, &, #, `, and W, so nothing is set in stone yet.

In the meantime though, I'm happy to be back!

Seems odd that Unicode would randomly add characters in Plane 9.  Are you sure it's not a fan extension or something?  I can't seem to find any info...

I actually did notice that (especially the curves on bdpq)!  Totally wasn't intentional though lol

I agree.  I've so far been unable to find an adequate simple slope without changing the width:height ratio (the closest I've been able to find mathematically is 16:23, which incidentally is the ratio of an A4 sheet of paper).  I'm not really fond of either using such a complicated slope or changing the width:height ratio, as I still (for now) want to keep GSU 3 compatible with GSU2.  But I'll keep looking, as the / shape is a pretty critical slope.  The other concern is that I'd have to find a way to fix / without damaging any of the other slopes....

NZz07/#\% have been fixed.  W<>^ have also been altered.  Q&~*` are next on the list, as well as perhaps touching up some of the nudged bricks, because I'm not sure I've done them as efficiently as I could've.  Thank you Peter (Petruuccio) and erictom333 for the advice though!  They definitely look a lot cleaner now.

@BWM I may end up having to go that route, though I'm not sure yet.  Is there one in particular you'd recommend?

@ctcg_ I will add Latin-1 Supplement, as I plan to make this a pan-Unicode font, but I'd like to make sure I'm happy with all of the basic Latin glyphs before I move onto anything more complicated.

I fear the nudging technique is lost on me.  I'm not sure if it's something I'm missing, but it seems to be difficult/impossible to stack nudged bricks.  For example, Ø, which would normally be constructed with O and /, does not seem to want to cooperate.  I may find a way to fix this, but in the meantime I'm writing off the imperfections in the /-like slopes as a style quirk (and at least they're symmetrical).

I will see what I can do then… may require more math than I'm usually capable of though lol

In an attempt to replicate the nudged bricks for the main diagonal slope I have come across two solutions (fig. 1).  The smoother approach (and the one I'd prefer) would be more like the composite in fig. 3 (which would be created by fig. 1B), although I am unsure how to actually do this considering that I can't make a composite brick out of already-composite bricks, nor can I make a composite out of more than 16 bricks.  fig. 1A, which uses bricks that are able to be made composite and creates fig. 2, is the current nonpreferred solution.  Though the jaggedness may not be visible for usual typing sizes, I'd still want to perfect this slope as much as I can given how essential it is.

So my question is: are the 2x3 slopes in the 4x4 composite space, as shown in figs. 1B and 3, possible to create, considering the constraint of a maximum of 16 bricks per composite, and if so, how?  If they aren't, would it be better to try to combine nudged bricks in cases like Ø or to try to redo the aspect ratio and/or try using 2x2 filters?

I apologize for the continued questioning, as I feel like this is something basic I should know by now, but I do want to get this right.

Also, @erictom333, is there a way to contact you on Miraheze?  I'm regrettably mostly unfamiliar with creating and maintaining wikis.

I believe I have fixed it, at least for the most part, so thank you so much!  More minor edits coming soon.

Yes I will eventually

In the pursuit of making my glyphs smoother, I've discovered that I need so many different slopes (especially composites) that it's becoming a bit difficult to manage.  If I scale this up, the number of composites I'd need would decrease greatly.  I had initially wanted to keep the size of my glyphs about the same as GSU 2.0 to keep them compatible, but I'd imagine that if they're the same ratio (e.g. 9:13 and 36:52) it wouldn't make any difference.  Am I correct in this assumption?  The only other sticking point would be that it might have an impact on performance, and I'm not sure whether this is the case either.

The above picture is just an example and won't be the exact change if I do go through with this option.

@BWM It probably is too thick - I meant that to be more of an example of how I'd scale up the font, but I'd of course refine it so that the lines are equal (or as close as mathematically possible).

@kyt1336 It may not be, and it certainly isn't high up on my priority list (I'd like to do most natural/Unicode scripts first, if I can, before moving onto the UCSUR.  I'll figure out how to deal with it then.

@erictom333 Thank you (although I don't seem to be able to clone it)!  I do have all of the slopes anyway, thanks to you and djnippa, but my concern was more that there would almost be too many slopes and I don't know if it would have more of an impact on performance than is necessary.  Of course, FontStruct isn't necessarily designed to have pan-Unicode fonts without at least some performance compromises, but I wonder if it would be better to have more slopes and fewer overall bricks or more bricks but fewer slopes.

Thank you once again!  I should have all of the slopes I need that are possible though; the issue is that some aren't.  For example, the grave and acute accents are about 1/8 of a block too thick (not really noticeable, but mathematically off), even though the angle is correct.  I can technically make them the correct width, either by nudging or by slopes with slightly different width, but at the cost of symmetry.

Scaling up the font, such that, for example, each current block becomes a 4x4 set, would fix this problem and also let me have a more limited set of bricks while keeping the sloping/smooth aspect, so I'm leaning toward this as the solution.  Am I correct in assuming that if the width:height ratio stays the same, so does the size of the downloaded font?  If so, I may attempt this in a private font and move it over to here once I have it figured out, as it shouldn't really affect the look of things too much besides cleaning up a few odd points.

For example, the leftmost is the current grave at a 1:2 slope, which is about 1/8 of a block too thick, and the second to the left is the next thinnest legal symmetrical 1:2 slope that I've found, which is about 1/8 of a block too thin.  The third grave has the correct thickness, but is asymmetrical.  This is fine for something like the asterisk, which has a vertical bar in the center to hide the necessary offset rotation, but fails for something like the dz ligature.  The fourth example is the optimal symmetrical version of the third grave, but contains slopes which are unable to be formed into a composite.

Technically, scaling up each brick in this font even to 2x2 would fix this issue, which I had initially wanted to do, but may come with its own set of issues even though it may solve several others.