mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-04-24 21:56:10 +03:00
[GH-ISSUE #2400] Strange behavior with Japanese dakuten and handakuten characters (examples ギ、パ) #914
Labels
No labels
Atrac3+
Audio
CPU emulation
D3D11
D3D9 (removed)
Depth / Z
Feature Request
Font Atlas
GE emulation
Guardband / Range Culling
HLE/Kernel
I/O
Input/Controller
MP3
Multithreading
Needs hardware testing
Networking/adhoc/infrastructure
No Feedback / Outdated?
OpenGL
PGF / sceFont
PSMF / MPEG
Platform-specific (Android)
Platform-specific (Windows)
Platform-specific (iOS)
PowerVR GPU
SDL2
Saving issue
User Interface
Vulkan
arm64jit
armjit
armv6
x86jit
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ppsspp#914
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @akemin-dayo on GitHub (Jun 22, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/2400
The UI appears to give the dakuten and handakuten characters their own character space, which is incorrect behavior
Dakuten and Handakuten are the circle and " markings you see on some Japanese characters
Like the " in "gi" -> ギ
Or the circle in "pa" -> パ
To reproduce the problem: put the characters ギ and/or パ in a filename and view it in PPSSPP.
Dakuten and Handakuten display properly in the PPSSPP pause screen.
EDIT: Screenshot attached. 「コードギアス 反逆のルルーシュ LOST COLORS」 is the title.
@unknownbrackets commented on GitHub (Jun 22, 2013):
Are these combining characters or something? I wonder if this is related to how they're being encoded specifically in filenames, rather than in the game's sfo.
-[Unknown]
@akemin-dayo commented on GitHub (Jun 22, 2013):
They aren't combining characters. At least, they shouldn't.
@lioncash commented on GitHub (Jun 25, 2013):
This may have been fixed with my recent commit. If the issue still exists, just tell me and I'll try to fix it.
@akemin-dayo commented on GitHub (Jul 7, 2013):
No, this issue has not been fixed.
@lioncash commented on GitHub (Jul 7, 2013):
I'll see what I can do tomorrow
@adrian17 commented on GitHub (Aug 27, 2013):
Just an update, the bug is still present with the new UI.
@lioncash commented on GitHub (Aug 27, 2013):
I'll try and look into it when I have time (currently working on the UI for the Android version of the Dolphin Emulator). I'll try to find time tonight to get a basic look at what's going on.
@hrydgard commented on GitHub (Aug 27, 2013):
I just tried it and it works fine for me. Weird.
@adrian17 commented on GitHub (Aug 28, 2013):
I just checked, it works fine on my Android phone too. The screenshots above were from the iPhone 4.
@hrydgard commented on GitHub (Aug 28, 2013):
This really shouldn't be different between platforms. Did you use a custom built ui_atlas?
@adrian17 commented on GitHub (Aug 28, 2013):
I didn't touch it, it happens on a freshly installed Testing build. The file was just cube.elf renamed manually on the phone with iFile.
@thedax commented on GitHub (Aug 28, 2013):
Seems to be fine for me on my PC..that's really weird.
@akemin-dayo commented on GitHub (Aug 28, 2013):
For those who are curious as to what @adrian17 means by "Testing build," I have 2 release "channels" running on KarenBuildBot, each updated at different intervals.
The "Testing" channel is simply the one that gets updated after every push, as long build is successful (the new KarenBuildBot will refuse to upload if the build fails)
That being said, I can confirm that this issue still happens. I'm going to attempt a clean build of all KarenBuildBot projects to see if that fixes anything.
EDIT: The clean build did nothing. Oh well, it was worth a try.
@unknownbrackets commented on GitHub (Aug 28, 2013):
What are the bytes of the filename (e.g. from readdir)? It really looks like the filename (perhaps just on iOS) is using combining characters and our font renderer simply isn't combining them.
-[Unknown]
@unknownbrackets commented on GitHub (Sep 2, 2013):
So, I confirmed that this can be a combining character. For example, here:
ﾞ ﾟ
Those are combining characters. Here's some regular characters:
キ ヘ
And here's them next to each other, compared to a regular character with the mark:
ヘ ﾟ ペ
In some cases, inputs will auto combine these characters I think? I don't really know the rules well, but I do know that in Japanese these are typically only used as combining characters with half-width kana, since the character set doesn't include these marks for half-width glyphs.
Here's half vs full:
ﾍ ヘ
And with the mark vs full with the mark:
ﾍ ﾟ ペ
I suspect that for whatever reason, your filename contains combining characters, while the game title (included in PARAM.SFO) showing in the pause screen does not.
-[Unknown]
@xsacha commented on GitHub (Nov 25, 2013):
So the naming method that iFile (in iOS) uses isn't compatible with our font atlas.
I think this can only be resolved by rendering with native fonts, right? Eg. what is currently done in Windows and Qt.
@hrydgard commented on GitHub (May 15, 2014):
@angelXwind is this no longer an issue? When closing after a long time, it's good if you post a short message stating that it's fixed or some other reason why the issue should be closed.
@akemin-dayo commented on GitHub (May 15, 2014):
Sorry about that, accidentally hit the close button on this one, tried to stop it, and mobile Chrome ended up crashing.
@akemin-dayo commented on GitHub (May 15, 2014):
Also, @xsacha: iFile is a third-party application... I'm sure that's not the cause here.
Perhaps you were trying to refer to CoreText or something similar?
Renaming the file using
mvstill produces the same bug, so I don't think it's something wrong with the filesystem (which is HFS+, same as OS X)@unknownbrackets commented on GitHub (May 15, 2014):
http://stackoverflow.com/questions/9757843/unicode-encoding-for-filesystem-in-mac-os-x-not-correct-in-python
"MacOS X uses a special kind of decomposed UTF-8 to store filenames." "In particular, the HFS+ filesystem uses UTF-8 encoding, and normalisation form D (which requires composed characters like ö to be decomposed into o¨)."
So they most likely are indeed decomposed characters.
I'm not saying this is wrong, but our font routine currently doesn't handle decomposed characters well. We could either:
-[Unknown]
@xsacha commented on GitHub (Jul 1, 2014):
@angelXwind For now you can use the Qt build (which won't have this issue) to get correct fonts.
It should build fine in iOS and Mac OSX (otherwise send me the error).
Long-term, we'll need to use one of the solutions suggested by @unknownbrackets
This glitch does happen in OSX as well, right?
@unknownbrackets commented on GitHub (Apr 11, 2020):
Going to close this as a duplicate of #9958. As mentioned by xsacha, Qt, Windows, and Android should now render this right using native font rendering.
-[Unknown]