MicroTeX icon indicating copy to clipboard operation
MicroTeX copied to clipboard

Mac/Apple support

Open bitjeep opened this issue 2 years ago • 7 comments

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.

bitjeep avatar Jun 23 '22 16:06 bitjeep

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 avatar Jun 23 '22 21:06 sp1ritCS

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

sp1ritCS avatar Jun 23 '22 21:06 sp1ritCS

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 avatar Jun 23 '22 21:06 bitjeep

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 avatar Jun 23 '22 23:06 bitjeep

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).

bitjeep avatar Jun 24 '22 00:06 bitjeep

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.

NanoMichael avatar Jun 27 '22 07:06 NanoMichael

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).

bitjeep avatar Jun 27 '22 15:06 bitjeep