this is a question I have posed already in two forums for different aspects (keyman and oxygen XML product forums), but I suspect there is a more general issue which I fail to see.
I have Keyman installed on Mac OS X and would like to use it with Word, libreoffice, oxygen or other software to type ethiopic script. However the behavior is quite strange in my understanding.
If I type a combination to obtain a character like 'h+a' I expect to obtain 'ሀ' but I get 'ሀh' or typing b+a to get 'በ' I get instead 'b በ'
In TextEdit for example this works fine and I do not understand why it does so in word and other editors.
Any suggestion on how to solve this?
Keyman for Mac OS X is a beta release product. This means that it has known issues and is being made available for testing. So, this is a known bug in the beta release of Keyman for Mac OS X. At the bottom of the Keyman for Mac OS X home page you can see a list of known issues, and the relevant issue is:
Keyman does not detect context correctly in Open Office or LibreOffice or MS Word 2011 14.4.3.
There's not much you can do to solve the problem yourself, bar typing in TextEdit and pasting into other editors (which isn't practical). I am on the Keyman developer team and we are aware of the issue and are working on it.
Related
I installed Racket 8.5 on my MacBook (MacOS Ventura Beta) and ran into a number of problems:
the application windows don't close on the cross, even the ones that are considered additional menus and shouldn't work that way anyway. Add video
In projects from my computer, the functions do not work correctly. And this error appears even if I move the author's code into my Racket in a clean project. For example, from a project downloaded from the Internet, where the author writes:
empty-scene 100 100 "blue"
In his project everything works fine, this function is in the Racket documentation.
If I write this function in my project, Racket gives me an error;
empty-scene: expects only 2 arguments, but found 3
I tried to find information about this on the Internet, I reinstalled Racket and downloaded different versions of the program, but the problem persists.
Has anyone encountered similar problems? Are there any tips on how to fix it?
I have no idea about the window thing: this doesn't happen on macOS 11 and I suspect is an artifact of running it on some beta version of macOS.
The arguments are because you're not in fact using 2htdp/image but htdp/image, which provides a different version of empty-scene. This is clear from looking at your video.
Also, please provide a description, in text of what is needed to reproduce problems like this: images and videos are just not a useful thing.
I'm coming back with results! Your messages are confirmed. It turns out that everything was affected by the beta version of MacOS. After rolling back to Big Sur, both problems resolved.
Thanks so much Shawn and ignis-volens for looking at the problem from the outside and helping me solve it 🔥
I'm trying to find a modern environment similar to what I found great about QBasic but making up for the flaws. The purpose of this is to code with my 6 year old son.
I'm looking for an IDE that uses a modern language, has the ability to draw graphics and play audio, and doesn't force the User to jump around much between coding and running their application.
In QBasic you had basically two modes: Edit and Run. There were no third party libraries required for creating graphics or generating Audio tones (that I remember). You never had more than one "window" opened at a time.
Is there a modern day equivalent IDE which uses a modern language that provides what I'm looking for?
I don't want him to have to jump around between various windows, try to wrap his mind around window toolkits, understand the command line, or use OOP just to get started. My end goal is to create simple graphical games with him -- not printing text out to the console.
(Preferably cross platform or useable on Mac OSX since that's what we have at the house. Preferably Python based since that's my language of choice.)
QBasic is a great option. You can purchase an old PC from a thrift store and run QBasic on it. There is the option of QB64 which can run on both Mac and Windows. Hope this is helpful.
I'd suggest QB64, almost 100% compatible with QBasic/QuickBasic but runs on Windows.
You could maybe try Small Basic, it aimed to recreate the ease-of-use and educational purposes of the old BASIC languages build into home computers from the 1980s
The Small Basic project was initiated following this article on Salon:
Why Johnny can’t code (David Brin, 2006)
I want to make a little painting program. So i am going over if it's even possible. As with all good painting programs it needs to have pressure sensitivity. And i don't think i have ever come across anyway to get pressure sensitivity of mouse/tablet. Is there a workaround.
The thing i have come closest to is touch event that is supposed to have pressure property.
This question has been asked before but that was like in 2009. I am hoping that there would be something available this time.
Chrome apps are also an option.
As far as I know only Firefox support this through a proprietary property on the event object:
var pressure = event.mozPressure;
which keeps a value between 0.0 and 1.0.
Wacom has a plugin that can be installed to give browsers an API to read these sort of values from but I guess it only works with their own tablets.
Hello from the future world of 2022!
There is a PointerEvent API that appears to be supported by major browsers, and pressure can be read out from the PointerEvent.pressure property.
tldraw is an example of a project using this API.
Notes on operating system support for this:
macOS
I can confirm pressure-sensitivity with tldraw's drawing tool works for me on macOS, with either Chrome or Firefox, and a cheap Wacom tablet. Safari did not.
Linux
Chrome on Linux works out of the box; I used the Flatpak version. Your mileage may vary with the .deb or Snap package.
For Firefox, you may need to do this or this to get pressure-sensitivity working. There seems to be a regression with Xinput 2 support being tracked by bug #1207700, so maybe this will be fixed some day.
Windows
I don't imagine you'll have any problems on Windows, but I'm unable to test.
If you were interested in creating a web-based paint program in 2022, you might have a look at Pressure.js, which claims to support both pressure input and "3D Touch" present on some Apple devices in a single library. I have no first-hand experience with this library, though, so I can't back up those claims.
It's true this comes 9 years too late for your project. Sorry about that. But this question ranks high in search results for "pressure sensitivity javascript api," so perhaps it can still be useful to someone.
SmoothDivScroll is wonderfull script! But does anyone know if the new beta version of SmoothDivScroll (version 1.2) is working in IE 6, 7 and 8? I saw in the google Group of Thomas Kahn that this questions was also raised. I'm trying to get it working but can't get some features working and I don't know if it is my mistake or not. I hope Thomas himself sees this post and will react on it. And if the conclusion is that it is not working on these versions of IE, I would like to know if Thomas will work to get it also on IE working or if he leaves it as it is now. Of course I hope this, because it is wonderful code!
Jan
Yes, SmoothDivScroll 1.2 should work OK in older versions of Internet Explorer. I don't have a computer that is old enough to have a "real" installation of IE6 but I do have a virtual machine running Windows XP SP3 and Internet Explorer 6 (which is basically the same thing as a real installation).
When I tested on this machine there was one issue that had to do with the height of the hotspots. For some reason the hotspots do not fill out the entire height of the scrollable area. Currently I have no fix and to be perfectly honest I don't think I will spend time looking for a solution since IE6 is a browser that is becoming more and more marginalized. If anyone has a solution - let me knoe! I haven't made up my mind about IE7 yet. But I do want it to work fine in IE8 and IE9 though since these two versions are alive and kicking.
Two follow up questions:
Which features are not working and in what versions of
Internet Explorer?
Do you have a demo somewhere that I can look at? Since
SmoothDivScroll is a plugin that depends heavily on the surrounding
code on the page, in many cases errors in the HTML and/or the CSS is
the source of the errors.
Then again - sometimes the bungling is on my part. It's been known to happen. :-)
OK, I don't do much .Net programming, but I do have one that I maintain, so the answer to this may be obvious.
Setup:
Windows 7 Ultimate with All Language Packs Installed
Visual Studio 2008 Winforms VB.Net project.
I'm in the process of localizing this project, and when I'm making the Japanese version of the forms, the characters display as squares, though they render in my browser correctly. I'm guessing that this is because the default font does not have a glyph for those characters.
So, my questions:
Are winforms UTF-8, or some other character encoding?
Is there a way to change the character encoding?
Should I change the font for the Japanese forms, or will Windows do it?
What's the general best practice here?
I want to know that I am copying the characters correctly into my forms, and I want to be able to test them. How can I do this?
Thanks for any feedback!
EDIT:
Thanks for the info! Here's what I've found.
Arial Unicode MS does have all the glyphs, but I wasn't using it, because it wasn't in the VS2008 list of fonts. I manually edited the font box to use it, but then Visual Studio throws the message, "Attempted to read or write protected memory. This is often an indication that other memory has been corrupted." I'm guessing that's because VS doesn't have permission to access that font for some reason. I go back to the default font, scary error message goes away.
Then, even when using Arial Unicode MS, the text renders as blocks in the forms titles. Same text renders correctly in labels.
So, I think I want to use the default font, and let Windows handle it. I think I've read that everything from XP on will handle it. Windows 2000 won't, which is a shame, but what ever, I don't know what font I should use, and whatever font it is was excluded from VS. I don't know how to add it without getting lots of error messages about protected memory.
Now the problem is, resizing the labels in the form, since the translated text is often larger.
Also, I don't have a support team to do this for me, but I could maybe install extra copies of Windows 7, and change to the Japanese language pack and try to run it. But that becomes a major pain. I thought I read that you could change the language while the application is running, but that doesn't seem to be true. MS docs talk about how to do this, but Windows 7 also tells you that you have to log out to change the language.
MS Gothic seems to work, and it's part of VS 2008, but the title bar is still squares. That's really odd, since the same glyphs are in the winform. Is that because title bar fonts are set at a system level, and not the application level?
Sorry for being wordy. Not sure that there is even a question here. Just trying to get it all out, so maybe this will help someone else down the line.
Any .NET code, including Windows Forms, uses Unicode encoded as UTF16. Your problem isn't likely to be an encoding issue, that produces question marks instead of squares. Getting a square indicates you are using a font that is missing the required glyph to display the Japanese character.
You can use the charmap.exe applet to find out what glyphs are supported by the font you use. If they are missing then the operating system is forced to fall back to a substitute font and fail at it when it cannot find one. Displaying squares is then all it can do. An old operating system version is a very likely cause for this mishap, particularly so for XP without the optional East Asian fonts installed.
Do note that this font problem is very unlikely to be an issue on a machine that boots the Japanese version of Windows. It will have to proper fonts to display Japanese text of course. You can get specific language versions of Windows through an MSDN subscription. At least get one for your QA staff so they can verify that everything works correctly.
Here's a great read on your issues from Joel Spolsky.
Just to be clear, did you install the language support: Control Panel / Regional Options / Display Languages. Presumably you've got Japanese text in the source code. You're saving the source code as some sort of Unicode, right?
For 3 years I've maintained a Japanese forms-based app (www.jbrute.com) which migrated from MFC, to WinForms to WPF across US English versions of XP, Vista and Win7. It displays Kanji, Kana and Uses the IME. No grief whatsoever.