search

NanoMichael / MicroTeX

A dynamic, cross-platform, and embeddable LaTeX rendering library
MIT License
403 stars 67 forks source link

Mac/Apple support #126

Open bitjeep opened 2 years ago

bitjeep commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

bitjeep commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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