I'm using CGContextShowGlyphsAtPoint in my application to render characters that follow a path. I'd had no problems with this at all until I started on i18n of the application and found that Japanese characters appear fine everywhere apart from when I try to render them using this function.
Is there a way to have these characters appear properly, as opposed to being rendered as empty boxes? Stupidly, I didn't see this coming (newbie iPhone developer) and I really need to support these characters :(
I've been searching stackoverflow and google all day but seem to be getting nowhere with this.
Thanks for any help you can offer,
Bryn
This is a very similar question to your own. Basically, it is very difficult to get the appropriate glyphs for doing pure Quartz drawing of text, so I recommend using the NSString UIKit category method -drawAtPoint:withFont:. This will get you all the support that NSString has for languages, while letting you draw directly to a Core Graphics context. It's what we use in the Core Plot framework for text rendering within a CALayer.
However, drawing this way is much slower than pure Quartz text rendering, so if you're doing a lot of text drawing it could slow things down in your application. Also, the UIKit extensions to NSString take into account the flipped graphics context of UIViews and their CALayers, which has caused others problems.
I did not know this, but I did some digging and I'll tell you what I found:
The Quartz2D Programming Guide refers to the "ATSUI Programming Guide" but has no active link.
Google turned up a cached copy of the legacy ATSUI Carbon API here
Apple states here that you should not use ATSUI, but instead use CoreText
There is an open radar to port CoreText to iPhone since 31-Jul-2009 12:54 PM
Sorry mate :(
Related
In iOS 7 some of the most important string drawing and metrics calculation methods were depracated with no obvious alternative given.
The page on NSString UIKit Additions Reference is red like blood. Almost everything deprecated. Xcode throws 300 warnings at me.
I try to find out what was running through Apples mind and what they changed in UIKit text system but where would I start? Did they mention somewhere why all of this is deprecated and how the text system works different now? And how to adapt? How to calculate text bounding box when label can scale the font to fit size? Is TextKit the solution?
I spent 3 hours on Google but I found no useful information on how to solve this problem.
We should document all alternatives here so all developers who run into this depressive deprecation mess find peace of mind quickly.
If you look at the deprecations, most of them deprecate the use of UIFont to use a dictionary of attributes instead.
drawInRect:withFont: (Deprecated in iOS 7.0. Use drawInRect:withAttributes: instead.)
drawInRect:withFont:lineBreakMode: (Deprecated in iOS 7.0. Use drawInRect:withAttributes: instead.)
sizeWithFont:(Deprecated in iOS 7.0. Use sizeWithAttributes: instead.)
etc…
So if you're looking for a place to start, learn how to use dictionaries of attributes to set up fonts. It looks like a lot of deprecations, but you don't actually need to learn that much new stuff.
If you want to update your code to use the new TextKit system, check out the WWDC videos and the TextKit Programming Guide.
If you want to know Apple's reason for deprecating so much, I'd guess that it has to do with how UILabel and UITextView used to be built on web views, now they're built on TextKit.
I've read in the documentation that the NSString category method drawInRect is good for small amounts of text, but is too much overhead for large amounts. The alternative in my case would be to use Core Text CTFrameDraw.
My question is, what is the "cut-off" point between using drawInRect vs Core Text? Is Core Text always faster than drawInRect? If the extra programming is not the issue, should I always just use Core Text instead of drawInRect, even for small strings?
Mostly I'll be drawing paragraphs, but sometimes they can be short lines too.
For me it comes to use core text when I have some specific requirements from the graphic designer. For instance label that need to mix colors, type, font size etc. drawRect is method that draws something in a view layer, is just a wrapper around CG functions, core text is full framework to deal on how to draw text: change fonts, spaces, interlines.
I mean is not fair as a comparison, a better question could be when it comes to use core text instead of common UI text porpoise obejects and the answer is based on your app design-UI related requirements. Hope this helps.
I would write some test code to benchmark the two methods under consideration using your expected statistical distribution of string content. Maybe a timing a few tens of millions of string renders using each. Run the benchmarks on an actual iOS device, as relative performance may be different using the ARM targeted frameworks.
I wonder if using a UIWebView would get all the performance that's possible. The iOS (and every OS) has a constantly loaded webkit ready to go. Its pretty well optimized too. It would also get work offloaded.
Interesting to compare.
Is there any simple text editor available for iphone having features like BOLD, ITALIC and changing colors and fonts? I want to add this functionality to my iphone app.
Any help will be really appreciated.
You have to develop it through Quartz2d.In otherwords ,you can through handling CGContext of UIView. see the Quartz2d programming guide.for example you can give bold font through
CGContextSelectFont (context,"Helvetica-Bold",12, kCGEncodingMacRoman);
Text Editor Pro seems to have those features. Pretty expensive though: http://itunes.apple.com/dk/app/text-editor-pro/id316815447?mt=8
Oliver Drobnik (aka Cocoanetics) is working on a rich text editor for iOS.
It won't be free, unfortunately. However, he has released a sizeable chunk of code that serves as the foundation of his rich editor here: https://github.com/Cocoanetics/NSAttributedString-Additions-for-HTML
It takes HTML and turns it into core text. A lot of hard work right there.
That, on its own, is not a rich editor, but like I said, it serves as the foundation of one. You could use it to write your own, if you don't want to pay up for Oliver's when he's finished. You can see what Oliver has been working on here: http://www.cocoanetics.com/2011/01/rich-text-editing-on-ios/
I have a set of tiled image collections created via Microsoft's Deep Zoom composer, and a Silverlight application that currently consumes them for display via MultiScaleImage - it's all working pretty well - I'd just like to get some experience with iPad programming and
have a couple of ideas for some iPad applications. All my ideas rely on me being able to display/manipulate these tiled image sets (on the iPad).
I just picked up a iMac to facilitate this. I'm not seeing any Objective-C / Cocoa-touch libraries for this though, so am assuming I will have to roll my own. (I saw the Seadragon Ajax component, which is pretty slick, but I'm dealing with collections here, which it doesn't support. I would also like to roll this as a native application just to get the experience.)
The only open source project I found for displaying/manipulating the tiled image sets was Openzoom - a Flash component. I'm not to familiar with ActionScript either (Python, Java, C#, and c are the only languages I have really used), but briefly inspecting the code I didn't really have any issues with it and can probably use it for hints on how to swap the tiles in and out, etc. But, as I'm pretty new to Objective-C/Cocoa-touch, some pointers in the right direction would be appreciated.
1) Are there any other projects out there I am missing, or is OpenZoom my best bet for some reference?
2) Should I be trying to do this display in the UIKit framework, or should I do it as an OpenGL display?
3) Any other suggestions/pointers that I didn't think to ask.
I have just been working on a few apps that rely on tiling large images to allow for deep zooming. I found a couple of examples but the best and most useful for me was Apple's "PhotoScroller" sample code.
It relies on CATiledLayer to handle the tiling. The result is an extremely smooth and responsive interface even with very large images and its not too complex. (A little complex but not too bad).
So to answer your question directly:
PhotoScroller Code
QuartzCore Framework (which is part of the SDK)
There is a great, free little mac app for slicing images into tiles that I use a lot: "Tilen"
In the WWDC 2010 source samples, under iOS, there is a project in the ScrollView Suite called Tiling. It corresponds to WWDC10 session 104. It is probably the best image tiling example out there.
You can take a look at they way RouteMe library does this, the dynamic loading of higher resolution tiles, panning, etc. https://github.com/route-me/route-me
I can't believe nobody has told you about UIScrollview; the UIScrollView component is designed for this very purpose! (think Google Maps, which uses it).
Check out the class reference...
UIScrollView
The delegate method you require is the following....
- (UIView *)viewForZoomingInScrollView:(UIScrollView *)scrollView
This allows you to check the zoom level, offset etc and then provide a view for zooming. This way you can maintain your 'position' within the tiled landscape independently of the graphics used to represent it.
Don't roll your own UIScrollView, no need to!
Take a look at CATiled Layer. See my answer to a similar question here: Drawing in CATiledLayer with CoreGraphics CGContextDrawImage
What are some suggested "paths" for getting better at drawing in code in Cocoa? I think at this point, that's my biggest weakness. Is drawing in code something general, or Cocoa-specific?
Thanks!
- Jason
The best way is probably practice. Try drawing some simple things at first: a calendar (basically a grid), a custom button, or a digital clock.
Its also worth noting that a lot of 'custom' controls are made from images, so not that much of the drawing is done in code -- the only thing the code does is stitch those images together.
You might want to look at Opacity, a drawing app for OS X (I'm not affiliated with these folks, just discovered the app a few days ago). What sets Opacity apart from other drawing apps is that it can create Quartz code directly from your drawings. Naturally, the generated code is not perfect but in the few days I've been trying this app I've found it to be quite helpful in understanding how to use Quartz more effectively.
Drawing in code is need for creating custom controls no matter what UI toolkit you pick. Drawing in code certainly has its advantage, for example the application/framework that you are building is really lightweight come production time, cause there will be lot let resources(images/fonts/etc) to worry about.
Also if a problem arises changing drawing in code is a lot easier than to redo code and images together.
If you are doing Cocoa drawing start by looking at source code of BGHudAppKit and reading Cocoa Drawing Guide by Apple.
I'm in the same boat as you; I'd like to learn more about drawing code.
It's a big document, but the Quartz 2D programming guide on the developer website seems like a good place to start from. They introduce Graphics Contexts and Paths and include plenty of images.
There's also a book referenced in that document, Programming With Quartz: 2D and PDF Graphics in Mac OS X which looks good. The APIs for iPhone and OSX are almost identical, so there's no problem using a Mac OSX book.
So I'd suggest start with the Apple documentation (you don't need to read past the section on CGLayer drawing), try some sample code and figure out how it's working. Then move on to either that book or find more sample code on the web. Good luck!