Source file overview (out of date, but goes over the.Hotkeys for Menu commands and other actions.Lookups, Features, Scripts and Languages.Introductory concepts: fonts, splines, lines, points and.
#DEFINITION OF NON INTEGRAL VALUE FROM FONTFORGE HOW TO#
Even if there is not though it would be useful to understand how Fontforge is assessing this error, so that is clearer how to correct it. The absence for an obvious explanation here and the different validation result in an earlier version of Fontforge still makes me thing there must be an issue. In fact sometimes a point is picked that has no glyph at it all, whilst positions representing significant numbers of glyphs are ignored. The one thing I have noticed though is that the values that Fontforge picks for both the lower BlueValues and the OtherBlues don't always make a lot of sense when the histogram is looked at. Working out why with each of them seems equally complicated in each case. Looking at some other fonts created by different people I have noticed that this reported validation error is quite common: Using -46 0 and a BlueScale of 0.021739 doesn't work for example. The only thing that is different here from what has been tried before is changing the lowest BlueValue to reflect a more representative position on the scale, although it is not obvious why this particular combination has been accepted when similar ones weren't before. Then the BlueScale is altered to reflect this. It also moves the lower value from -46, which Fontforge had picked apparently because it was the lowest deviation point, to -36, which was a much higher concentration of lower deviation points on the histogram. In the Blue Values it places one value at 0, which is the theoretical baseline, however, I had tried that before and it didn't change the validation result. As I have said, trying different permutations of the values that appeared to be correct according to the Adobe documentation did not alter the Fontforge validation result. The values given above are what Fontforge guesses at, both the earlier version that the font was begun with and the 03-09-2014 build. Reply to this email directly or view it on GitHub #1711 (comment). Values below the baseline should be in OtherBlues, BlueValues is for ascenders. Subject: Re: Blue Values / Blue Scale validation error appears incorrect ( #1711) I am not an expert, so am happy to be corrected if the issue is not what I think it is, although there is still the issue of different versions of Fontforge reporting the problem differently, which makes it additionally difficult working out what the issue with the font (if there in fact is one) might actually be.įrom: Adrien Tétar [ 02 September 2014 16:13 The Adobe documentation also confirmed that the upper value in the BlueValues was sufficiently separated to be valid when I first looked into this. ‘Alignment zone height in BlueValues/OtherBlues array is too big for BlueScale.’ The error message when it can be made to appear is this, which was eliminated previously by recalculating the BlueScale after investigating what the problem was likely to be: There would be no bottom zone in the BlueValues if they appeared in OtherBlues. BlueValues below the baseline also seem to occur in other fonts with traditional characteristics. The font is based on an old typeface and the spread around the baseline is a characteristic of it. Altering the upper value to 0 to place it on the nominal baseline does not seem to make any difference either. This is a bottom-zone.’, which is indeed the case here. Well Fontforge places them there and moving them to OtherBlues does not resolve this.Īccording to the Adobe documentation on this, referring to the BlueValues, ‘The first pair is the baseline overshoot position and the baseline.
0 kommentar(er)
