new bliss chars and misc fixes

[hlridge]

As we know, using words/synonyms as identificator creates some problem. Number id:s would be good to use instead. Is it better to wait to do this change or is it better to try to do this change at the same time as the incorporation of this pull request?

[matlun]

This pull request looks fine to me with the following questions/comments:

About the preserveAspectRatio: So is this not a boolean value in SVG, right? But why is the xMinYMid value the right one to choose? Please explain to the curious ;-)

About steeringwheel: For many of the characters with side-ways oriented pointers that exceed the skyline above their base characters, it has been discussed whether the indicator position should be adjusted to the upward extension of the pointer or not when there is no immediate proximity involved. The simple solution is of course to follow the general rule also taking these pointers into account. Should be checked up with Michael Everson. In a quick check I find the following relevant ones: chimney 13168 finger 14180 fur,coat(animal),hair(animal) 14415 hair(head) 14661 hip 14713 point,tip,peak 16212 wrist 18284 equator 22598 North_Pole 22600 soprano 23952 bottleneck,bottle_opening 25529 horseneck 25571 mane(lion_etc) 25580 steering_wheel 26062

[hlridge]

The SVG attribute preserveAspectRatio is used to tell that the aspect ratio of the svg image should remain the same even if the image container has another aspect ratio. xMin/Mid/MaxyMin/MidMax tells how the image should be aligned in the container. xMin is left aligned, xMax is right aligned, xMid is horizontally centered. yMin is top aligned, yMax is bottom aligned, yMid is horizontally centered. See https://codepen.io/tigt/pen/GJRveM . I believe the container in this case is automatically set to the same aspect ratio, so what value that is chosen, if at all, probably doesn't matters in this case. Not setting the attribute at all gives the default value "xMidYMax". If you don't want to keep aspect ratio you can give the value "none". I am not 100% sure the letters' width is entirely correctly given, so I felt that left aligned was the safest bet, while for y I had to pick one (the container height should always be the same in bliss, anyway, so...), so the choice become xMinYMid. I am sure Google can find you a more in-depth explanation about the attribute. :)

[matlun]

Thanks! Yes, I have of course found lots about this, but helpful and interesting to get your rationale for the precise choice here, which seems very reasonable.

[hlridge]

Diagonal arrows use arrowheads that greatly differs from horizontal/vertical arrows which use arrowheads with legs of length sqrt(8)/8≈2.83/8≈3/8 . arrow_(bent) (2/8), ascending_and_descending (4/8), downward_and_backward (4/8), downward_andforward (2/8), reflection (2/8), reflection(mental),consideration (2/8), shine (2/8), upward_and_backward (4/8) and upward_and_forward (4/8). In "fundamental rules" examples of arrows in all 8 directions has been drawn, showing all arrowheads use legs ~ 3/8, both horizontal/vertical and diagonal, however the odd shapes used in WinBliss seem to have always been there so until it is really clearified what opinion BCI has regarding this, I will revert the arrow changes from the last commit.