I have a project including a JSON file which contains Arabic text.
I copied the text from a Word Document file into the JSON file in Xcode.
As far as I know, the correct bits of text in the JSON file are usually shown in red and
the incorrect bits are shown in black color.
This is what it looks like in Xcode:
There are plenty of parts in my JSON file where text is shown in black, hence it must be incorrect. When I run the app, which should output the arabic text in a tableview, the
tableview is shown as empty.
Thus, there must be a problem with the JSON file.
I also checked it on http://jsonlint.com/ with the JSONLint Validator. It showed me the following error message in the red box at the bottom:
Here is the JSON file containing the Arabic text:
https://www.dropbox.com/s/5gxdqmh2l9lr7cv/MyFavoriteDishes_ARA.json
I don't know how to fix it! It's frustrating. Any help is appreciated!
Related
Since iOS8, the behaviour of Mail with the pasteboard seems to have changed.
I am trying to copy both images and text from my app, in a format that I can paste into the Mail app.
A UIPasteboard containing both images and text will only paste the images into Mail. A pasteboard containing one or the other works fine.
I create a dictionary for each text and image element, add them all to an array, then set pasteboard.items to the array. This method has worked for a year or two.
My guess would be that Mail now takes the "best" data in the pasteboard, and assumes that the text was included only as a fallback (such as a text description).
Has anyone else observed the same problem, and is there a workaround?
When I tried to add some text and a image to the UIPasteboard a few days ago, I found that ONLY the image was added to the UIPasteboard.
UIPasteboard.generalPasteboard().string = text
UIPasteboard.generalPasteboard().image = image
I use the code above then check UIPasteboard.generalPasteboard().string was nil, I firmly sure that my text wasn't nil. So, this may be a bug.
My app uses unicode characters. These characters (not the actual codes) are pasted directly into a PLIST file and then imported.
Some of them are not appearing correctly in UILabel and UIButton
When I print them to the log in Xcode they appear normal, but when displayed on the iPhone/Simulator some of the characters turn into an "alien in a box".
See image for example of problem (screenshot from UIButton titles)
My guess is that the font you are using does not define these characters. Select a font (or build one into your app) that includes the characters you need.
When I write arabic text containing the letter kasra (unicode character 0x650, phonetic equivalent i) to a button, the kasra is not displayed. Thus, the word mumkin appears as mumkn. If I inspect the NSString in Xcode, the kasra is present, but the kasra is not displayed in the iPhone simulator or on a real iPad. The other two short vowels (fatha and damma) are displayed correctly.
The arabic letter kasra (unicode character 0x650) is missing from all of the built-in IOS7 fonts that i have tried.
The solution was to build a different font into my app- I used AGA-Rasheeq-Bold.
This may be a bug. I just tried it in the storyboard editor and it does not seem to work. I created a string in the MAC Notes application, copied and pasted. It displays correctly in the left hand properties panel, but not in the button itself. Could you provide the exact Unicode string? You may need to open a bug report with Apple.
I can confirm that it works correctly in a Label field, but not a Button (IOS 6.1 and Xcode 4.6.3)
Try attributed text. This seems to work around the issue.
How do I keep the same spaces that exist in the file .txt? In .txt file it says:
text :text
text1 :text1
text23 :text2
text345 :text3
if I write this code:
Memo1.Lines.LoadFromFile('Text.txt');
this appears in the Memo1:
text :text
text1 :text1
text23 :text2
text345 :text3
the text is different from the file. txt.
The file will be loaded faithfully. All whitespace is preserved exactly as it is in the file.
The most plausible explanation for what you observe is that your text editor displays the file differently from how the TMemo control displays it. Possibly your file contains tab characters. These are often displayed differently in different viewers. Or perhaps the text editor uses a monospace font, and your memo control does not.
But I stress again, the file will be loaded faithfully. The contents of the file are loaded into the memo control without alteration.
You could use a propotional Font like Courier.
Or better format your text with TAB.
I am using iOS 4.3 and Apple's suggested method for printing a PDF, which is to set the shared UIPrintInteractionController's printingItem property to an NSData object containing PDF data. It's very easy, which is great, but I've found that when printing a PDF via this method, the content starts 4mm lower on the page than if I print via Preview.app on my Mac. As I am printing to pre-cut labels, precise positioning is important.
It appears that somewhere in the process, a (blank) header is being added to the page, which is causing the content to shift down the page. The resulting horizontal margins are the same on both iOS and Mac OS X so I suspect it really is a header, and not an all-around margin.
I have checked the following:
Is the printer adding the header? No, because the same results can be seen when printing to the Printer Simulator.
Is the iPad using a different paper size to the Mac? I have used the delegate method to ensure that the UIPrintPaper is the same for both.
Can I edit headerHeight for the UIPrintPageRenderer? No, because a renderer is not created when setting a printing item directly.
My workaround is to make the PDF generator (the server) create the PDF content 4mm higher up than it ought to be, but this breaks printing from Mac OS.
Out of ideas now! Thanks for any assistance.
You should check Apple's sample code PrintWebView. I believe the problem your having is because of the hardware margins. See SIMPLE_LAYOUT constant in PrintWebView sample to learn more. Hope this helps.