I am creating an HTML String from an NSAttributedString using the Category' s html method. Since _iOS6TagsPossible is false on OSX 10.8, colors are ignored by the renderer.
I've quickly patched DHTMLWriter just for testing:
#if __MAC_OS_X_VERSION_MAX_ALLOWED > __MAC_10_6
_iOS6TagsPossible = YES;
and it works. (NS)Colors in AttributedStrings seem to be stored under the NSForegroundColorAttributeName Key, not under kCTForegroundColorAttributeName.
Maybe this has nothing to with Mountain Lion at all but with OSX in general?
It is likely OS X in general since OS X support in DTCoreText only came as a by-product of me wanting to be able to run Unit Tests on Mac as well.
OK, good to know that. We just switched to DTCoreText for our OSX Editor and iOS Framework. If I stumble across OSX issues I'll patch them and send pull requests.
Hey, nice to hear! Happy to have any contributions you might have!
@artifacts actually it would be better in this case to totally remove the ios6possible thing and always check first the CoreText kCT* constants and then the new NS* constants if those are nil. This way it would work for all scenarios.
Could you please make these changes and possibly also add a unit test for DTHTMLWriter that checks if a color is picked up?
@artifacts there is problem with the earlier suggestion of removing the ios6possible things. When executing on iOS 5 those constants are invalid. Which is why the check needs to be there and needs to be enhanced like you suggested.
Or somebody knows an alternative to using the OS version for the check. Unfortunately those constants seem to have a value, so you cannot check against nil.
I've encountered another problem: If the color is CMYK, the hex conversion fails:
2013-02-11 01:13:43.088 Purple[93003:303] *** -getRed:green:blue:alpha: not valid for the NSColor NSCustomColorSpace Generic CMYK colorspace 1 0 0.4 0.32 1; need to first convert colorspace.
2013-02-11 01:13:43.092 Purple[93003:303] (
I've started porting the DTAttributedTextView classes to OSX (we need the exact same text rendering on OSX and iOS) and will fix this in my branch.
@artifacts Any progress?
We're still busy porting the view classes to osx, might be finished at the end of the week. We also added support for hyphenation marks (will be added automatically at the end of a line when necessary). Fruthermore, we added (non static) Frameworks to the projects because of header mess. We felt that it's more comfortable to use frameworks which contain all headers on osx that to tweak the header search paths ... anyways, I'll send you a pull request as soon as it's ready so you can decide yourself if you want to put it into the main branch.
Having a normal dynamic framework is the ideal method for OSX.
How are you doing hyphenation? Is that built in on Mac or is that introducing an external dependency?
Currently we're doing hyphenation outside of DTCoreText this way: http://blog.tupil.com/adding-hyphenation-to-nsstring/
As far as I understood the hyphenation file licenses it should be OK to integrate it into DTCoreText, at least for DE and EN ...
BSD means that people using it have to attribute it. So you can add support for it, but should detect at runtime if the classes/categories are available and only use it if they are.
Also the problem is that hunspell is GPL/LGPL/MPL which - as I understand it - means that software using it must remain free. So unless I am misunderstanding this I cannot accept this into a project that commercial software is using.
@artifacts We can add a hook into the string builder class that would pass text through a hyphenator before adding it to the building attributed string. There you would add your hyphenation stuff, independently of DTCoreText.
But please DO NOT include hyphenate in your pull request. You can add a read me how to hook it up.
I understood the MPL as OK for commercial projects: http://www.oss-watch.ac.uk/resources/mpl
I'll keep hyphenation out of DTCoreText, but I leave the hyphen mark stuff (before, DTCoreText did render NSAttributedStrings containing hyphens properly, but without the "-").
Generally I would prefer if we did this bit by bit as to avoid merge conflicts or duplicating code unnecessarily.
@artifacts What's your status on this? Any change of a merge soon?
@artifacts your response?
I've pushed our changes into a fork on github: email@example.com:artifacts/DTCoreText.git
It's in the branch osxrendering which is based on your master a few weeks ago.
Neither have I merged it with the newest changes from your branch nor have I tested it thoroughly yet. We're in the midst of a product release and working on different checkouts for several projects which might not be in sync yet ...
I cannot guarantee that we did not mess things up in the project file but since shipping products has a higher priority right now we just have to make things work. I want to do a cleanup in the next 2 weeks to not let the projects drift apart too far.
But it seems that we have reached the goal of having exactly the sample pixel-perfect rendering on both osx and iOS, which is quite important for us.
Great! I'll definitively update before cleaning up ...
2 months?!? damn, time is running fast.
we had so much "fun" with git submodules (4 levels, arrrrrgh) merging and branching in different projects in the last months... all fear is gone ;)
this is what you get if you try to merge your branch into the current master:
warning: Failed to merge submodule Core/Externals/DTFoundation (commits not present)
CONFLICT (content): Merge conflict in DTCoreText.xcodeproj/project.pbxproj
CONFLICT (content): Merge conflict in Core/Source/DTHTMLAttributedStringBuilder.m
CONFLICT (content): Merge conflict in Core/Source/DTDictationPlaceholderView.h
CONFLICT (content): Merge conflict in Core/Source/DTCoreTextLayoutFrame.m
CONFLICT (content): Merge conflict in Core/Source/DTCoreText.h
CONFLICT (content): Merge conflict in Core/Source/DTAttributedTextView.m
CONFLICT (content): Merge conflict in Core/Source/DTAttributedTextView.h
CONFLICT (content): Merge conflict in Core/Source/DTAttributedTextContentView.m
CONFLICT (content): Merge conflict in Core/Source/DTAttributedTextContentView.h
CONFLICT (submodule): Merge conflict in Core/Externals/DTFoundation
Automatic merge failed; fix conflicts and then commit the result.
Have fun fixing the merge conflicts in the project file ... :-)
PS: When you finally DO start working on the merging you can ask me any time via skype TheDrops or iChat/AIM/iMessage firstname.lastname@example.org what certain changes are for.
We can also do the merge together over screen sharing in the near future if that helps. You know how to get in touch.
I am also very much interested in making Mac functionality a part of DTCoreText's functionality.
Say, how did you work around Mac's absence of the run delegate? Did you implement attachments?
PS: you are missing so many goodies and bug fixes.
Proper underline drawing to just mention one
Nice idea, we should do this...
No attachments yet since we have our own layout engine and texts are only one type of widget we render. Users can assemble the layout by using multiple text boxes. But I definitively want to have text floating around objects in the future. Did you dive into css regions? Maybe this could be exiting to implement.
@artifacts I was hoping to get your Mac stuff merged before doing the next big advancements so that there is not too much of a difference. Any progress there?
@artifacts it would be really nice if this were merged some time soon. How's your status?
@Cocoanetics We pushed everything for you to review in the branch osxrendering_merge 4 months ago: https://github.com/artifacts/DTCoreText/tree/osxrendering_merge
seems like a misunderstanding... ping me via Skype to discuss how we can proceed.