Author Topic: Characters incongruity  (Read 6045 times)

0 Members and 1 Guest are viewing this topic.

Offline bartok

  • Newbie
  • Posts: 80
    • View Profile
Characters incongruity
« on: August 12, 2021, 12:38:48 pm »
Hi,
how we can see in the attachments there is a difference between some characters in the IDE and a text editor. The same difference for character like "à, è, é, ù, ò" and so on. For example, if I write "à" in a text editor, in the IDE, I have a different character. If I write "à" in the IDE, I have a dofferent character in the text editor.

Is there a way in order to have the same characters opening the file in the IDE and in a text editor?

FellippeHeitor

  • Guest
Re: Characters incongruity
« Reply #1 on: August 12, 2021, 12:51:56 pm »
The IDE natively operates in Code Page 437, using all original ASCII line drawing characters. Other editors must be configured to display such characters - you will have to either change font or encoding in those.

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
Re: Characters incongruity
« Reply #2 on: August 12, 2021, 01:14:21 pm »
Programming isn't difficult, only it's  consuming time and coffee

Offline Bert22306

  • Forum Regular
  • Posts: 206
    • View Profile
Re: Characters incongruity
« Reply #3 on: August 12, 2021, 05:16:16 pm »
Indeed, old thread. It turns out that the first few characters in the original IBM extended ASCII characters set, those common accents used in French, Italian, Spanish, British pound symbol, and so on, are the same in the IBM original extended character set, and in UTF8. But then, from character 166 on, they diverge.

From my own point of view, I use the drawing symbols of that original IBM character set, 176-223, so I'm happy with the IDE set up be default as it is. Of course, editors that use UTF8 will show weird stuff.

I don't know about the Euro versions of MS Word, but the US version allows you to choose what ASCII extension you want, when opening a file which includes characters beyond 127.

Just wanted to add, for some reason, in their original extended ASCII, IBM was biased to French, and languages that use the same accents as French. And also biased to a subset of Greek symbols, not all of them. The more odd characters used in German and the Scandinavian languages are not included.
« Last Edit: August 12, 2021, 05:23:53 pm by Bert22306 »

Offline Fifi

  • Forum Regular
  • Posts: 181
    • View Profile
    • My small QB64 contribution
Re: Characters incongruity
« Reply #4 on: August 14, 2021, 02:20:08 pm »
Just wanted to add, for some reason, in their original extended ASCII, IBM was biased to French, and languages that use the same accents as French. And also biased to a subset of Greek symbols, not all of them. The more odd characters used in German and the Scandinavian languages are not included.

Hello Bert22306.

The reason is obvious: the size of the market.

I wonder if QB64 will adopt the same philosophy!

Failing to follow this path shows a certain form of arrogance and disrespect for the non-English native developers who are legion.

Just my two cents.

Cheers.
Fifi
It's better to look like an idiot for a short time while asking something obvious to an expert than pretending to be smart all your life. (C) Me.

Offline Pete

  • Forum Resident
  • Posts: 2361
  • Cuz I sez so, varmint!
    • View Profile
Re: Characters incongruity
« Reply #5 on: August 14, 2021, 06:04:01 pm »
Those other countries can kiss my White privileged ascii. If it's so important to them, why don't they ban together and make Third-World-BASIC? We could do our part by donating _MAPTRIANGLE, so they could auto-cad their mud hut villages. Oh wait, did someone mention Italy in this thread? Yes! Well, that makes this a whole different story. The Development should jump on this immediatamente!

In all seriousness, I have been bitten in HTML coding by some of those Italian Unicode characters. I use QB64 to sort them out, when parsing those pages. So kidding aside, certainly it would be nice to be as universal as possible, but to what degree of effort? What about Mandarin characters or more diversely put CJK? Do we have that working yet in QB64?

Also, forgive my spoof on the "arrogance" issue. As a hobby language, the few people who contribute to the advancement of QB64 have to pick and choose the most beneficial additions to the platform. For instance, would it be better to make more programming features or try to make the language more universal? Certainly if we had developers from China, Japan, and other countries working on the project, things might be different. Certainly if we had millions of users world wide, the same would apply. Frankly it's amazing to me the project is as universal as it is, but it's like my mamma always used to say, "It's always something!"

Good night my little Roseanne Roseannadanna,

Pete
Want to learn how to write code on cave walls? https://www.tapatalk.com/groups/qbasic/qbasic-f1/

Offline Fifi

  • Forum Regular
  • Posts: 181
    • View Profile
    • My small QB64 contribution
Re: Characters incongruity
« Reply #6 on: August 16, 2021, 01:23:03 pm »
Those other countries can kiss my White privileged ascii. If it's so important to them, why don't they ban together and make Third-World-BASIC? We could do our part by donating _MAPTRIANGLE, so they could auto-cad their mud hut villages. Oh wait, did someone mention Italy in this thread? Yes! Well, that makes this a whole different story. The Development should jump on this immediatamente!

In all seriousness, I have been bitten in HTML coding by some of those Italian Unicode characters. I use QB64 to sort them out, when parsing those pages. So kidding aside, certainly it would be nice to be as universal as possible, but to what degree of effort? What about Mandarin characters or more diversely put CJK? Do we have that working yet in QB64?

Also, forgive my spoof on the "arrogance" issue. As a hobby language, the few people who contribute to the advancement of QB64 have to pick and choose the most beneficial additions to the platform. For instance, would it be better to make more programming features or try to make the language more universal? Certainly if we had developers from China, Japan, and other countries working on the project, things might be different. Certainly if we had millions of users world wide, the same would apply. Frankly it's amazing to me the project is as universal as it is, but it's like my mamma always used to say, "It's always something!"

Good night my little Roseanne Roseannadanna,

Pete

Hi Pete,

Thanks for your fun post.

I have always appreciated your humor and as a Frenchman, I do not feel at all insulted by your message which makes me laugh.

However, let me tell you that I fundamentally disagree with one important point:

If you are rightly saying that there are not enough developers contributing to the development of QB64, one of the main reasons is that even today, this surprising language is nothing but a hobbyist project.

Why ? Precisely because there are too many limitations in its code to make it evolve easily.

Now, if integrating vWATCH64 into the IDE seems like a very good idea to me, for QB64 to become a world-class tool for example to be accepted by the Raspberry foundation, I think the following steps must be taken:

1- separation of the IDE code from that of the compiler so that the latter can finally behave really like any other classic compiler (example gcc). This would allow, among other things, to see developers concentrate on the evolution of the language itself, and other to take care of the IDE. Some time ago, Fellippe told me that this should not pose a big problem. And that would also make it possible to interface with other IDEs easily.

2- extracting all the "messages" from the IDE code and setting up these messages in external files. This would make it very easy to create multiple translations in different languages. In addition, it is so easy to do and does not pose any technical problem. This also makes it possible to offer a dynamic change of language. Cf above for developpers wanting to contribute to the project when only translating the messages.

3- Unicode support and in any case at least no more default setting in code page 437. Indeed, as said above if the extended character table of IBM and Microsoft was "European biased", the reason and that this choice was not binding for English-speaking developers but simultaneously opened their tools to all European developers who alone represent a much larger market than that of the USA.

4- that vWATCH can work with programs placed in subdirectories and also with large programs (see my post: https://www.qb64.org/forum/index.php?topic=4123.msg134750#msg134750 )

There are surely other points to be addressed but these first 4 seem to me really essential for QB64 to acquire a real place on the worldwide market to gain millions of users (and developpers).

And adapting QB64, InForm, and vWATCH64 for use on Raspberry 4 seems like a great way to get there ... except to let Google and Microsoft take their place once again.

BTW, your telling about the number of contributors is the story of the snake that dies its tail.

Cheers.
Fifi
It's better to look like an idiot for a short time while asking something obvious to an expert than pretending to be smart all your life. (C) Me.

FellippeHeitor

  • Guest
Re: Characters incongruity
« Reply #7 on: August 16, 2021, 01:35:27 pm »
Quote
this surprising language is nothing but a hobbyist project

That's exactly what it is.

Quote
for QB64 to acquire a real place on the worldwide market to gain millions of users

Not in the plan.

We're going as we're having fun. I have a day job to bring bacon home. This is where I have fun.

Sorry to disappoint. We plan to keep having fun.
« Last Edit: August 16, 2021, 01:44:15 pm by odin »

Offline Petr

  • Forum Resident
  • Posts: 1720
  • The best code is the DNA of the hops.
    • View Profile
Re: Characters incongruity
« Reply #8 on: August 16, 2021, 02:11:08 pm »
I personally don't mind. Windows dialog boxes write text correctly and legibly, even though the text in the IDE source code is unreadable. But there is a possibility to use fonts in the IDE. It's just text, it can't be used to translate disk paths (for example, you can't open files in diectories with unicode names) but it can be handled by direntry.h by StevemcNeill (and a big thank you for that). You can use _MAPUNICODE in your programs, so if you find out what code page your computer uses (the library I use for this is here: https://www.qb64.org/forum/index.php?topic=2014.msg112399#msg112399) then you can write in the program as you need. It will be ideal to use an external file written in an editor with supported accents for the texts in the program and then display it correctly thanks to _MAPUNICODE. I think that _MAPUNICODE clearly proves that the QB64 team thinks of people who do not use English but also other characters.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: Characters incongruity
« Reply #9 on: August 16, 2021, 04:28:25 pm »
I’d also like to point out that one can also use QPrint with unicode, as well as my KeyHit library, which can be mapped to any keyboard configuration imaginable.  It’s not like it’s impossible to use QB64 with any codepage/hardware out there — one just has to be willing to use the proper libraries to do so.
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Cobalt

  • QB64 Developer
  • Forum Resident
  • Posts: 878
  • At 60 I become highly radioactive!
    • View Profile
Re: Characters incongruity
« Reply #10 on: August 16, 2021, 07:33:30 pm »
In all seriousness, I have been bitten in HTML coding by some of those Italian Unicode characters. I use QB64 to sort them out, when parsing those pages. So kidding aside, certainly it would be nice to be as universal as possible, but to what degree of effort? What about Mandarin characters or more diversely put CJK? Do we have that working yet in QB64?

Don't forget the Braille so we don't discriminate against the visually challenged.
Granted after becoming radioactive I only have a half-life!

FellippeHeitor

  • Guest
Re: Characters incongruity
« Reply #11 on: August 16, 2021, 07:57:49 pm »
I have actually been approached by a blind user recently who used qb64 but not the IDE, because our text mode is actually graphical and his screen reader couldn’t help with it.

Offline Fifi

  • Forum Regular
  • Posts: 181
    • View Profile
    • My small QB64 contribution
Re: Characters incongruity
« Reply #12 on: August 17, 2021, 09:45:22 am »
Sorry to disappoint. We plan to keep having fun.

Sorry Fellippe but I do not see the connection between "having fun" and extending the use of QB64 to the greatest number and especially to the most disadvantaged children of all languages ​​who are the privileged target of the Raspberry foundation.

So, is QB64 a private garden, kind of a closed club for adults only?

Honestly, I didn't see it that way.

I'm disappointed. It seriously lacks empathy.
It's better to look like an idiot for a short time while asking something obvious to an expert than pretending to be smart all your life. (C) Me.

FellippeHeitor

  • Guest
Re: Characters incongruity
« Reply #13 on: August 17, 2021, 09:47:29 am »
Quote
"having fun"

That's our goal.

Quote
extending the use of QB64 to the greatest number and especially to the most disadvantaged children of all languages ​​who are the privileged target of the Raspberry foundation

That's never been our goal.

Offline Fifi

  • Forum Regular
  • Posts: 181
    • View Profile
    • My small QB64 contribution
Re: Characters incongruity
« Reply #14 on: August 17, 2021, 10:07:38 am »
That's our goal.

That's never been our goal.

It's a shame given the potential of this tool.

But I understand, maybe having more developers would make you lose your hand on the toy.

Too bad.
It's better to look like an idiot for a short time while asking something obvious to an expert than pretending to be smart all your life. (C) Me.