Note that this also works on round rooms - the pixmaps do have to be scaled down by a 0.707 factor to allow for them to fit inside the small extremes compared to the rectangle - but this code does not force rectangular/square rooms on those with letters/symbols as the prior code did.

Also note that Map Format 19 is not stable - I do have another separate PR in mind to give each room a persistent Uuid (Universally unique identification number) on creation which should make it easier to track changes between divergent versions of shared binary maps - as it will be easier to see which rooms have been added/modified/removed between two copies. However that will also need to store a QUuid for each room and although I can store it in the room user data for backward version compatibility it too, ideally, needs to be stored directly as an element of the binary data and it is my intention to also include that in the version 19 binary map format. The bottom line is that if someone tests this code and enables version 19 for testing the map data will not be readable if the format is changed again for that other feature - so do not use 19 for anything other than a test save that can be thrown away afterwards.

Anyhow - for an example in action, check out this:

Logged a bug report QTBUG-66204 because they did not mention that QFont::PreferNoShaping was only introduced in Qt 5.10... 🙁

1). I think it would be fair to say eventually in the Wiki that Emojis can be used but that is not the right word to describe the massively huge proportions of other glyphs that can be used - Emojis are only one type of ideograms and they are separate from logograms and phonograms that make up the symbols for Chinese (and others) and Roman languages respectively.

2). What is happening on that dialog? I can't see anything and I'd expect to see some content in a normal font in the other columns - it is only the two that show the glyphs that have non-standard font setting! Stick some ordinary letters in your map. I don't suppose that you are using an XML map format which does not currently support room symbols/letters?

3). What font are you specifically selecting - I have got some really poor results from some ropey bitmap fonts because I suspect the font matching routine tries to use glyphs from "other" fonts to fill in for missing ones from the selected one based at least partly on size in some aspect... it is possible that we might want to experiment in using QFont::setBold(true) or QFont::setWeight(n) for a finer control.

1. The wiki can mention that they are glyphs, but I'd say that in general we should use terminology people use and can understand, not technical terminology which they don't know and alienates them. Keeping things simple as possible is good, otherwise people don't understand and say the program is far too complicated!

2. "sag coun", see column 5

3. that was one of the variants of the Ubuntu fonts. Here it is with Symbola - not much better...

Is there any way to add colour to them?

1). I am not happy to use a word that is less than twenty years old (according to Wikipedia) to represent a very small subset of what can be used. Character is one that people will recognise but unfortunately in this day and age, character has a degree of ambiguity; however glyphs and graphemes though not quite the same thing (the former is the representation of the latter in a particular font) are much better representations of what is involved - as it is, symbol is the replacement term I have put on the 2D mapper context menu and in the context where this is used as a specific mark or combination of marks used to designate something it is not an unreasonable choice either.

2). Ah, you said: "...with rows too small..." but you meant columns too small! I agree and I think I can fix that. I've also realised that it is not wise to include every room in the last column - because a wilderness map with symbols on every room will just make the rows very large when auto-sizing-to-contents, I'm proposing to clamp it to, say 32 rooms, with a more, not shown... ending if there are more than that number. Like this, whilst using Ssalis's Aetherspace map:

This will still allow the usage of odd glyphs to be detected which was the intention but means that it is not a full-blown search feature {unfortunately I haven't found a way to make it possible to (context-menu) select and copy data from the dialogue, e.g. by copying the symbols or individual room numbers} so this is probably okay.

3). It is not possible to colour emojis as the Qt widgets concerned do not support {which is not surprising, really} handling/rendering of the Variation selectors that control this i.e. U+FE0E {VARIATION SELECTOR-15 (VS15)} for text or U+FE0F {VARIATION SELECTOR-16 (VS16)} for emoji style.

For example of those selectors in use, one probably has to use a broswer (or perhaps QTextBrowser but that is just not realistic for this in the Mudlet application) "😐😠︎😄️ 😐︎😠︎😄︎ 😐️️😠️️😄️️" the first three icons here are plain, the middle three have VS15 and the last three have VS16 appended - and in my FireFox browser the third and the last three render as coloured emojis, the first, third and last three are a larger diameter compared to the second one and the middle middle three - but it is possible that they will not be the same for other viewers of this text.

Curiously, choosing the Symbola font shows those Variation Selectors as separate glyphs but as it does not contain them it is not easy to work out where those glyphs are coming from - for example, using DejaVu Sans:

Using Symbola:

We've gotta think about the users here - I'd argue we're making the program for them. If we were making the program just for ourselves, yeah, we'd call everything the strictly 100% semantically correct terminology that very few users would understand. We're not working with a life-and-death situation here like I do at my work, I say we can relax the semantics in favour of people understanding.

That said emoji's are supposed to be coloured and if we can't get them to be coloured at all, then we shouldn't call them so. It'd be a big dissapointment. Can't we render the emoji in colour and then save that picture, and re-use it in the mapper?

Also, could you show me a screenshot of how your map looks like when this is working correctly? The results I've tried haven't rendered very well.

@Kebap @Ansrare @WackyWormer @keneanung you guys make use of the mapper as well, so if you could give your thoughts on this, that'd be great!

I vote for "symbol". I think both "emoji" and "character" both convey a much smaller set of options than are actually available. "Glyph" is a close second, and I think many english-speakers would be somewhat familiar with the term (e.g. Egyptian hieroglyphics), but IMO its a bit too esoteric for the average user.

I forgot to add the links to test this feature - they are a bit hidden. You can try this out for yourself:

Windows: https://ci.appveyor.com/api/buildjobs/j662o7wkpbnf15y4/artifacts/src%2Fmudlet.zip
macOS: https://transfer.sh/rM8Tl/Mudlet-3.7.1-testing-PR1543-7180991.dmg
Linux: https://transfer.sh/MZ5BY/Mudlet-3.7.1-testing-PR1543-7180991-linux-x64.AppImage.tar

I think I am going to have to have a play with the various QFont::XXXX flags for the style strategy to review what each of them does - it looks like some are mutually exclusive and it is not so obvious that I have chosen the best ones - for instance I think I set things to prefer outline to bitmap fonts - but it may be at small sizes bitmaps actually work better - also with the anti-aliasing, I think I preferred that option as well, but again that may not be the optimum choice either... 🙁

Okay, sure! Show us what you come up with.

Additionally, given an arbitrary map, how would I know which of the two functions to use? Getting a ? back is not correct, because it might also be an actual question mark.

The old one will return that '?' but also a second return which is a string saying that it should be changed to the new one - fair enough the user/scripter won't be looking for it - but if they start seeing a '?' instead of what is seen on the map one might guess that they'd RTFM.

I just dislike the naming anomaly getRoomChar/setRoomChar but realise we cannot get rid of them - so they just works in the way they worked before and should the user only use the single ASCII character they will not see any difference {other than that they can now delete the character from a script}. Don't forget that the return value from the new getRoomSymbol will be multiple bytes for anything that is not a single ASCII letter.

Though, if you @keneanung, as well as Vadim insist on only keeping one pair of functions i.e. getRoomChar/setRoomChar {instead of allowing the old ones to just be marked as obsolete from version 3.8 onwards and suggesting users use the new functions if they have them (which is one way but not the only way how we've added extra functionality in the past) - which is my preference} then I guess I will have to go along with the majority view - I just want to be sure we've covered all our bases before we finalise this...

Yeah, I think so.

How about a compromise: I note that there are some lua functions that are registered with a different name externally to what they are internally - and in one case this means there are two names that call the same function internally. As a bit of an aside I note that of the 303 functions that I can see declared in TLuaInterpreter right now, the following cases exist:

• clearWindow(...) and clearUserWindow(...) both use the internal clearUserWindow(...) function {The former is used in the external GeyerMiniConsole.lua script, the latter is not mentioned}.
• debugc(...) uses the internal debug(...) function {and is defined for both the main Lua instance and the indenter instances; debug is used in local function findStringEventHandler(existingHandlers, functionString) in the external Other.lua script and in some error handling for function mmp_mapping_newroom(_, num) in the script of the bundled mudlet-mapper.xml file}.
• echo(...) uses the internal Echo(...) function and is used extensively
• hideWindow(...) and showWindow(...) are mapped to hideUserWindow(...) and showUserWindow(...) internally respectively and are used in external GUIUtils.lua and GeyserContainer.lua files.
• handleWindowResizeEvent(...) is mapped to the internal noop(...) function and has dummy (empty) replacements defined in GUIUtils.lua, LuaGlobal.lua and has a commented out work around in the Geyser.lua file for "VERSIONS PRIOR TO 1.1.0" - indeed that file is currently completely commented out now!
• send(...) is mapped to the internal sendRaw(...) function and is used extensively in several external Lua files - however the internal TLuaInterpreter::sendRaw(...) which impliments it uses sendRaw in its error messages NOT send!
• wait(...) is mapped to the internal Wait(...) function, it is not used by any external script that we provide - but the internal TLuaInterpreter::Wait(...) does run a msleep(argument) on the thread that is running it - of course this is an evil thing to do so it is just as well as we don't use it or document it. 😈

This being the case, would it be acceptable to I have map ped the old getRoomChar(...) and setRoomChar(...) onto the new getRoomSymbol(...) and setRoomSymbol(...) respectively ?. This would mean s that the old names would still work but the functionality (and error messages) would be the same as the new command - so that we do not add to the total number of functions by adding this change but the old names still operate though we prefer everyone to use the new ones going forward ?.

Edit, updated 2018/03/11 00:30

@keneanung could you review the changed as well?

I don't think clearWindow and clearUserWindow is a mistake we want to repeat again.

I am not sure what you mean by that - perhaps it predates my starting on the Mudlet project, but this does provide a means to get past the fact that the original functions were perhaps poorly named or at least not really appropriate when their scope had been expanded beyond their original target.

This is the case. But the problem is, that this renaming is confusing the users (whom we create this software for). I was contemplating this kind of compromise as well, but explaining to a user why we have a set of functions that do exactly the same is not making the interface more intuitive.

Another thing about renaming that function is making scripts work in multiple Mudlet versions becomes a PITA, especially if one function is deprecated and I don't know when it will be removed. It forces me to write stuff like local var = (getRoomSymbol or getRoomChar)() which doesn't make the code more readable or maintainable. Leaving it getRoomChar and be done with it, even if not precisely named, takes a huge burden off scripters backs. If you want an example of using such a changed interface, have a look at https://github.com/svof/svof/blob/master/raw-svo.defs.lua#L2360 and following until the end of the function. There are a lot of these cases, which make scripting newbies shy away. I had to answer a lot of questions about that part.

Well I do not contemplate removing the old function names - until at least we have to redo things for Lua 5.2 or 5.3 because the Linux distributions no longer provide 5.1 (perhaps that will be needed for Mudlet 5.x where a major version number change would be mandated by such a backwards incompatible change)

Having both *etRoomChar and *etRoomSymbol still seem to me the best way to provide the backwards compatibility that existing scripts need whilst getting away from having to point out to new users that to get/set something that a reasonable person would call a symbol they have to use something that refers to a Char... 🙍‍♂️

I'm not contemplating removing any function names either - breaking people's stuff is just not a cool thing to do, even on major upgrades!

Given my practical experience of working with a lot of users, the confusion of having two functions will be bigger than the confusion of having something that refers to char. We might think our functions have super intuitive and clear names but to many people it's all jibberish anyway and they can't tell the difference until they memorize what each does.

So I'm still in favour of just get/setRoomChar and no new functions for symbols even though we call them symbols now. Practical experience as keneanung demonstrated taught us that multiple functions confuse people.

Plus, in case we're wrong on this, we could introduce the symbol functions later on. We can't however undo removing a function.

(If user commentary is inappropriate, I apologize in advance for polluting the comment stream and will happily accept admonitions.)

Speaking as a user and a developer, I've found it quite common to use character, glyph, and symbol interchangeably in everyday usage even among the developers in my communities, outside of specific technical discussion re: Unicode implementation and technical documentation.

As a developer I can appreciate more precise terminology and in this case I would agree that glyph is the most precise for this context, and this usage seems supported even in Unicode's own documentation and glossary where symbol isn't even elevated to a specific definition.

All in all, from a user perspective, it seems reasonable to me to simply retain *Char functions going forward, especially given that most platforms still provide (and most users seem to actually, er, use) a "character map" for browsing available unicode characters and glyphs.

⌚️ macOs builds are stalling (well starting then failing and re-queueing) at Travis at present - after around 12 hours one of the pair of them has succeeded but I'm having to wait for the second to conclude... 🙁

Yeah, the next big thing is getting the text spacing/selection/highlighting working properly - I've got improvements so far but not a total solution - but it would be good to fix it for 2018/04/08 - (3.8.0 😀)