I have a weird issue.
I’ve noticed that sometimes multi-line text will have a very large bounding box (y-axis only).
Calling reformatText() on the string fixes the issue, but the issue doesn’t always happen.
I’ve attached a sample project that shows the issue.
Thanks - almost certainly a bug. I will sort it.
Great!
BTW.
It would be awesome to also have the kerning table included in the character-to-character calculations.
There are cases where the text looks a bit odd. For example “Total” looks a bit like “T otal” because of the lack of kerning.
The kerning info looks fairly simple in the fnt file: first=left-char-code second=right-char-code amount=adjustment-amount.
Would it require a bunch of work?
All I was saying about the @2x issue is that Corona silently uses best available, whereas font manager gives a warning. Should be easy enough to fix on my end.
Okay, I thought my new issue was solvable, but now I’m not so sure…
fontmanager.lua:54: bad argument #1 to 'lines' (FILE\* expected, got nil)
Usually this is just me getting tripped up over not setting the right fonts directory, but I’ve made that change and it still can’t find the file.
BitmapFont.fontDirectory = "assets/fonts" -- where font files are, fnt and png.
My basic structure is app/assets/fonts for the font, app/code/ for the font manager
EDIT: Yeah, it’s definitely crashing because it lacks the @2x asset. Simply copying the .fnt and .png and adding the @2x issue stop the crash. I will look into adding fallback code.
That should hopefully be fixed by Ingemar’s work - I used my own code, Ingermar’s scans the image suffix table in config.lua
Kerning shouldn’t be too difficult because it reformats, so the reformatting should, theoretically, just have to be adjusted to sort the kerning. I want to figure out the bug reported above first (this will be tomorrow morning probably).
I don’t understand? The crash is strictly using the latest fontmanager.lua (a few minutes ago). Unless you mean the ingemar change you mention has yet to be integrated?
+1 on kerning, that would definitely help with the font I’m using. 
I added a new function called fm.BitmapFont:setFontDirectory() that you can use instead of modifying the module code.
As for the crash you’re seeing. I think there might be a bug if there’s no imageSuffix in config.lua.
Regarding the @2x warning. That’s on Android, right?
A font dir setter! Perfect!
No, the @2x warning is on OSX simulator (iPhone 5).
My config.lua has specific settings for @2x, @3x, @4x, but because I’m using GL_NEAREST I don’t always have assets for those resolutions. (It doesn’t make sense in many cases to carry a bunch more files if nearest neighbour scaling does the same job.)
My bad. That error message means it can’t find the .FNT file. I have added it to the issues to make it fail more gracefully and helpfully.
You can figure out what it can’t find by adding print(self:getFontFile(fontName)) before line 54. I will update it so it gives a more helpful error message.
I think it’s a side effect of Ingemar’s changes, the check was originally done when it was looking for font@2x.png font@4x.png and so on, so when it got the file name back it knew it existed.
I fixed the no imageSuffix entry bug which was crashing most of the demos which only had a very basic config.lua. The padding on characters that were images failed miserably as well. Not quite sure why but fixed it anyway
Yeah :( My change caused this to happen… sorry.
Well I can work around for now by using fake @2x assets. :)
Also found a pretty interesting Glyph Designer bug, for those who use it. Seems if you set an outer stroke, it always adds a +1 stroke. So outer stroke +2 is actually +1 stroke black, +2 stroke whatever colour you used. Center stroke doesn’t have this problem.
No problem, it is fixed (haven’t fixed the other one yet). It actually gives two warnings, the system call to get the directory gives a warning when the .FNT file is not found, and FM now gives out a similar warning.
Also found a pretty interesting Glyph Designer bug, for those who use it. Seems if you set an outer stroke, it always adds a +1 stroke. So outer stroke +2 is actually +1 stroke black, +2 stroke whatever colour you used. Center stroke doesn’t have this problem.
I haven’t seen that. I just tried by having a white font with a white 2px outer stroke. I see no black stroke included.
Weird.
GD version 1.9.2 (5666)
Hmm. Same version of GD. If I set a black (78%) 2px outer stroke I get 1px black, then 2px 78% black. The difference is only noticeable in Photoshop; GD’s preview only shows the 2px. If I set to grey (100%), then I just get 3px of grey (on a 2px setting)
I’m wondering if this could be caused by changing the font size (ctrl+) though…
Okay, so when I check the imageSuffix() it also needs to check the file actually physically exists ? I will add that as an issue.
Have fixed this by checking the file exists, the problem with this is it is belting out warnings because I use system.pathForFile() - I can’t find a system.doesFileExist() method, is there one ?
It works fine, it just belts out.
WARNING: Cannot create path for resource file 'fonts/demofont@2x.fnt'. File does not exist
for unavailable resolutions. Any ideas ?
I think so. In Corona itself basically all of the multires supporting functions will use @2x/etc if there and supported by config, but silently use the original asset if not. (I suppose they might also use best available, but I haven’t tested that). For developers this is helpful because there are all sorts of reasons why you might not have multiple versions of the same asset:
Nearest neighbor scaling means it would just be the same thing
You’re loading images from the internet
You don’t have another density of that resolution at the moment (for example, coding on the fly)
You’re using a new scale (ex: the likely @3x coming this fall) and haven’t done all the exports yet
It’s just too problematic to expect every resolution to be present on every build. This is why typically the way developers check for missing high res assets is to simply load the app and look for pixelation.
Yeah, I can confirm that the stroke-width is +1 in GD. Setting it to 0 produces a 1px stroke
However the color is solid. Maybe there are some other settings in GD that I haven’t set to get the behavior you’re seeing…
The resolutions is still fixed, basically as I suggested it just checks to see if the .fnt file is there, and picks the best. Minor downside is that it is belting out the warnings, which is Corona. Can’t find a silent way to check for the existence of a resource ?