Loading font with more than 127 Chars

[MasterLee]

The first error you will get at \128 which is an follow up byte but \127 is an singe byte character so the start for \128 is missing.
But even more the bytes in the range from 128 to 191 are all follow up bytes. 192 to 255 are start bytes that defines the length of multi byte characters

[ivan]

I've tried it with this:

Code: Select all

local glyphs = "\1\2\3\4\5\6\7\8\9\10\11\12\13\14\15\16\17\18\19\20\21\22\23\24\25\26\27\28\29\30\31\32\33\34\35\36\37\38\39\40\41\42\43\44\45\46\47\48\49\50\51\52\53\54\55\56\57\58\59\60\61\62\63\64\65\66\67\68\69\70\71\72\73\74\75\76\77\78\79\80\81\82\83\84\85\86\87\88\89\90\91\92\93\94\95\96\97\98\99\100\101\102\103\104\105\106\107\108\109\110\111\112\113\114\115\116\117\118\119\120\121\122\123\124\125\126\127\128\129\130\131\132\133\134\135\136\137\138\139\140\141\142\143\144\145\146\147\148\149\150\151\152\153\154\155\156\157\158\159\160\161\162\163\164\165\166\167\168\169\170\171\172\173\174\175\176\177\178\179\180\181\182\183\184\185\186\187\188\189\190\191\192\193\194\195\196\197\198\199\200\201\202\203\204\205\206\207\208\209\210\211\212\213\214\215\216\217\218\219\220\221\222\223\224\225\226\227\228\229\230\231\232\233\234\235\236\237\238\239\240\241\242\243\244\245\246\247\248\249\250\251\252\253\254\255"
Screen.font = love.graphics.newImageFont("res/font.png",glyphs)

But I got the UTF-8 error.

What I meant was, you can load your font as usual, but when you write stuff to the screen make sure you replace the non-printable characters.

Code: Select all

-- replace non-printable characters
function replace_control_chars(sz)
  local out = {}
  for i = 1, string.len(sz) do
    local b = string.byte(i)
    local c = '\\'..b
    if b >= 32 and b <= 126 then
      c = string.char(b)
    end
    table.insert(out, c)
  end
  -- rebuild string
  return table.concat(out)
end

The code is inefficient but should hopefully express what I was trying to say.

[zorg]

I said before that you can not have the character codepoints be ones that are part of utf-8's multibyte sequences, though now i'm questioning myself a bit, since i haven't actually tested this...

Let me give an example; let's say we have an image with 4 glyphs: a,b,c,á;
Now let's say, for whatever reason, we want to map those to x, y, z and 川.

Code: Select all

myFont = love.graphics.newImageFont("myfont.png","xyz\xE5\xB7\x9D")

Where "\xE5\xB7\x9D" is the byte representation of the UTF-8 codepoint for 川.

love.graphics.print takes utf-8 strings, so i want to assume that the glyphstring taken by newImageFont also works like that, hence the decoding errors you are getting; it's a bit strange since löve does not use separator characters there, but by my logic, the above should print the "á" glyph when you give love.graphics.print the 川 character (or the 3 codepoints i wrote above).

[bartbes]

love.graphics.print takes utf-8 strings, so i want to assume that the glyphstring taken by newImageFont also works like that, hence the decoding errors you are getting; it's a bit strange since löve does not use separator characters there, but by my logic, the above should print the "á" glyph when you give love.graphics.print the 川 character (or the 3 codepoints i wrote above).

Yes, love expects UTF-8 anywhere it expects a string (rather than a bag of bytes). If I'm wrong, that's a bug.

By the way, if your editor is set to save in UTF-8, the following also works:

Code: Select all

myFont = love.graphics.newImageFont("myfont.png","xyz川")

EDIT: As far as love is concerned, for fonts one (unicode) codepoint corresponds to one glyph, which is why this works without separators.

Might be worth noting that á would also have worked in this example, of course, it also consists of multiple bytes in utf-8. Though you can get into normalization issues there, since your editor could theoretically save it as "a combined with a ´ accent". Did I mention unicode is great?

[zorg]

Might be worth noting that á would also have worked in this example, of course, it also consists of multiple bytes in utf-8. Though you can get into normalization issues there, since your editor could theoretically save it as "a combined with a ´ accent". Did I mention unicode is great?

I mean, if you explicitly define the multi-byte sequence as i did, with the \x hex escapes, then the editor shouldn't mess with that.
It does take a bit of logic/math/base conversions and bit manipulation to figure out what codepoints decode to what sequences though.
(Or maybe it's already implemented in the utf8 lib, i haven't checked that either)

[MasterLee]

Might be worth noting that á would also have worked in this example, of course, it also consists of multiple bytes in utf-8. Though you can get into normalization issues there, since your editor could theoretically save it as "a combined with a ´ accent". Did I mention unicode is great?

Does that mean combined characters would not work?
I should test the following:
↑⃣ ↑⃣ ↓⃣ ↓⃣ ←⃣ →⃣ ←⃣ →⃣ B⃣ A⃣

[zorg]

Does that mean combined characters would not work?

Either that, or worse, both work; then of course you may expect interoperability between the two versions (pre-combined and combining) where no such thing exists.

Granted, this opens up another can of worms: if you can define two codepoints for an ImageFont to use, which basically map to the same character, but using these two different... i don't remember the correct terminology, so let's call them representational forms, then basically you could do something like the following, and get away with it... equivalent characters but one's pre-combined and the other isn't... it might be more apparent with the different hex-escape sequences, but i couldn't be bothered to look that up. :v

Code: Select all

love.graphics.print('áá')

?

[MasterLee]

Its even more dangerous for example 'BΒВ' that looks the same character but is encoded as 'B\xce\x92\xd0\x92'. Which is latin, greek an cyrilic B. So when you make an character starting with B in online games an they say the name is already taken simply use cyrilic or greek B. You could even make Ben when you need four character in some online games because your name has for bytes.

[zorg]

Its even more dangerous for example 'BΒВ' that looks the same character but is encoded as 'B\xce\x92\xd0\x92'. Which is latin, greek an cyrilic B. So when you make an character starting with B in online games an they say the name is already taken simply use cyrilic or greek B. You could even make Ben when you need four character in some online games because your name has for bytes.

I can only say to always sanitize your inputs.
In a more serious tone, i myself don't have any idea atm how that could be handled.

[raidho36]

Just don't. There's nothing to gain from implementing that.