Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mac/Apple support #126

Open
bitjeep opened this issue Jun 23, 2022 · 7 comments
Open

Mac/Apple support #126

bitjeep opened this issue Jun 23, 2022 · 7 comments

Comments

@bitjeep
Copy link

bitjeep commented Jun 23, 2022

I'm opening this issue to let others know that I'm working on Apple platform support right now (hopefully avoiding duplicate work). I have a branch in my fork named "macport" for this work. It's rendering all of the samples correctly in my test app. The only thing left to do is check the Windows & Linux builds to make sure I haven't broken anything, and clean up my test app.

Note that my changes should work on all Apple platforms. I'll test on iOS before submitting my PR since that's likely the one most people would be interested in.

@sp1ritCS
Copy link
Contributor

the cairo/pango renderer already has support for OS X (no idea about ios). It also compiles using apples clang fork. I don't really see why changing the string type to utf16 is needed.

@sp1ritCS
Copy link
Contributor

oh, nevermind what I said. all development is done against the openmath branch, which is a major rework of clm.

@bitjeep
Copy link
Author

bitjeep commented Jun 23, 2022

I don't really see why changing the string type to utf16 is needed.

I ran into problems with some of the utility functions not working as expected on Mac due to wchar_t size differences. I'll revert back to get the exact details of what didn't work. FWIW, UTF-16 interoperates far more nicely with native Windows and Mac strings (CAtlString and CFStringRef/NSString).

@bitjeep
Copy link
Author

bitjeep commented Jun 23, 2022

I ran into problems with some of the utility functions not working as expected on Mac due to wchar_t size differences. I'll revert back to get the exact details of what didn't work.

Looked through the diff and now I remember. It was the UTF-16 hexadecimal values used by tex::convertToRomanNumber, some constants in parser.cpp, and the wide2utf8/utf82wide functions. While UTF-16 characters can be used within 4 byte/UTF-32, byte ordering is a problem (hence why there can be a byte order marker in strings).

I also noticed that my search and replace of L" with u" was a bit aggressive. I'll fix those up.

@bitjeep
Copy link
Author

bitjeep commented Jun 24, 2022

ok, I see the work being done in the openmath branch (removal of wstring and Cairo rendering). I was trying to avoid completely removing wchar_t\wstring and simply replacing them with char16_t\u16string for consistency across platforms. Cairo does work on iOS (I've used it), but I like to use Quartz2D since it can draw directly to the GPU backing stores on Mac/iOS (super fast).

@NanoMichael
Copy link
Owner

Sorry for the late response. The main branch is NOT in maintenance now, and I'm working on the openmath branch to support Uni-math (or openmath namely) feature, which is a significant update. The first release of the openmath is on the way (yes, it should have been done 2 months ago...). So I suggest you make new features based on the openmath branch, there's no wstring anymore.

@bitjeep
Copy link
Author

bitjeep commented Jun 27, 2022

No problem at all. My mistake for not noticing the latest work on the openmath branch, I was doing some quick proof-of-concept work. What I'll do is port my Quartz2D rendering backend to the openmath branch and leave the u16string changes out. I agree with the strategy of just using std::string with UTF-8 (that's what I typically do).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants