Re: Printing questions

[Daryle Walker]

Sent from my iPhone

> On Mar 12, 2017, at 5:18 AM, Daryle Walker  wrote:
> 
> I hope it’s a nice first try, but I have some concerns.
> 
> 1. I also added an “Export as PDF…” menu item, which uses the save-as-PDF 
> default action. I guess it calls my code, but the docs for 
> “NSDocument.pdfPrintOperation” say I should use a separate print-information 
> objects for PDF mode. Does the default code take care of that already? Or do 
> I have to figure out somehow if I’m in print-to-PDF mode or regular print 
> mode and change the initialization of “info” above to be 
> “self.pdfPrintOperation” as needed?

And this is why you shouldn't post half-tired. It's "pdfPrintOperation," not 
"pdfPrintInfo," so my override wouldn't be called by definition. I guess I 
would override "pdfPrintOperation" to attach a custom print-info, but what 
should be in it? Is there some Apple sample code on this property? I didn't 
find it at all on GitHub. 


> 2. The RTF files I saved with the conversion operation have wrapping when 
> viewed through QuickLook. But the print-outs don’t do that; they do wrap, but 
> the limit is past the page margins so I lose part of the text. How can I set 
> the wrapping-mode/margins correctly.

I forgot to mention that another symptom was a second page appearing if the 
document only used one. I guess it was trying to represent the cut-off text on 
the right side. But it doesn't show up if more than one page is used. 

> 3. Are there any other (subtle) problems with the text-view code, since I 
> just took it from Stack Overflow?


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Unicode filenames with Apple File System and UIManagedDocument

[davelist]

(resent from address that is subscribed to the list)

Hi Uli, 

The code to create the URL was using:

   NSURL *url = [[self courseDirectory] URLByAppendingPathComponent:name];

where [self courseDirectory] is a URL of a directory (with an English name 
created by the app) in the Documents folder. The variable "name" is a NSString 
that is from the user (with just basic sanitizing to replace "/" with "-"). 
Note: this is iOS.

So I wasn't using UTF8String or fileSystemRepresentation.

Someone claimed I should be using fileSystemRepresentation and someone else 
said it shouldn't matter. If anyone has the definitive answer as to what I 
should change that to, I'm happy to use it (although it may be too late now).

Thanks,
Dave Reed

> On Mar 12, 2017, at 8:25 AM, Uli Kusterer  
> wrote:
> 
> I can't find the start of this thread, but this sounds a lot like you were 
> using -UTF8String instead of -fileSystemRepresentation to save out your file 
> names. That's the main difference between those two calls: 
> -fileSystemRepresentation decomposes UTF8 the way HFS+ does, so should never 
> adopt newer decompositions, and will instead guarantee the same string will 
> decompose the same way — as long as you don't forget to use it somewhere.
> 
> Of course, if you are using command line tools, they might not be properly 
> normalizing the file names.
> 
> Apologies if this was already covered in the lost beginning of this thread.
> 
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.de
> 
>> On 8 Mar 2017, at 22:35, Peter Edberg  wrote:
>> 
>> 
>>> On Mar 8, 2017, at 12:00 PM, cocoa-dev-requ...@lists.apple.com wrote:
>>> 
>>> Message: 1
>>> Date: Tue, 07 Mar 2017 15:03:41 -0500
>>> From: davel...@mac.com
>>> To: Alastair Houghton ,   David Duncan
>>> 
>>> Cc: cocoa-dev list 
>>> Subject: Re: Unicode filenames with Apple File System and
>>> UIManagedDocument
>>> 
>>> 
>>> 
>>> My app has the option to zip up the directories UIManagedDocument creates 
>>> and email it (so users can back up their data or share it with others). The 
>>> person sent it to me. Below is what I did in the Terminal so you can see 
>>> what happens when I try to unzip it. If this doesn’t come through on the 
>>> email list with the characters looking correct, I can screenshot it.
>>> 
>>> This is one of the data files that was created on iOS 10.2 and then won’t 
>>> open now on an iOS 10.3 device. It appears the directory name and zip file 
>>> name do not match and it won’t unzip correctly. It does create a directory 
>>> but the directory is empty instead of containing the StoreContent and 
>>> persistentStore files. The zip file is 34KB so it may or may not actually 
>>> have the data in it.
>>> 
>>> $ ls
>>> إعلام.zip
>> 
>> 
>> It is probably worth noting that the first Arabic character in the above 
>> filename (i.e. the one that appears on the right, adjacent to the period) 
>> has a canonical decomposition, as per this line from UnicodeData.txt 
>> (http://www.unicode.org/Public/9.0.0/ucd/UnicodeData.txt 
>> ):
>> 0625;ARABIC LETTER ALEF WITH HAMZA BELOW;Lo;0;AL;0627 0655;...
>> 
>> That is, in some cases this character 0625 (UTF8: D8 A5)  will be converted 
>> to the sequence 0627 0655 (UTF8: D8 A7 D9 95).
>> 
>> This decomposition was introduced in Unicode 3.0. If there are processes 
>> that use decomposition according to Unicode 9 versus Unicode 2.x, or 
>> processes that don't decompose versus ones that do, then the filename bytes 
>> will be different.
>> 
>> - Peter E
>> 
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/witness.of.teachtext%40gmx.net
>> 
>> This email sent to witness.of.teacht...@gmx.net
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/davelist%40mac.com
> 
> This email sent to davel...@mac.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Document drafts

[Daryle Walker]

Some of the API for NSDocument is oriented around draft documents. What is a 
draft and how does it differ from a non-draft? How do I create/open a document 
in draft mode? I didn't see anything about it in the Document guide; were 
drafts supposed to be a New World Order like auto-saves or versions, but got 
abandoned?

Sent from my iPhone
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Unicode filenames with Apple File System and UIManagedDocument

[Uli Kusterer]

I can't find the start of this thread, but this sounds a lot like you were 
using -UTF8String instead of -fileSystemRepresentation to save out your file 
names. That's the main difference between those two calls: 
-fileSystemRepresentation decomposes UTF8 the way HFS+ does, so should never 
adopt newer decompositions, and will instead guarantee the same string will 
decompose the same way — as long as you don't forget to use it somewhere.

Of course, if you are using command line tools, they might not be properly 
normalizing the file names.

Apologies if this was already covered in the lost beginning of this thread.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

> On 8 Mar 2017, at 22:35, Peter Edberg  wrote:
> 
> 
>> On Mar 8, 2017, at 12:00 PM, cocoa-dev-requ...@lists.apple.com wrote:
>> 
>> Message: 1
>> Date: Tue, 07 Mar 2017 15:03:41 -0500
>> From: davel...@mac.com
>> To: Alastair Houghton ,David Duncan
>>  
>> Cc: cocoa-dev list 
>> Subject: Re: Unicode filenames with Apple File System and
>>  UIManagedDocument
>> 
>> 
>> 
>> My app has the option to zip up the directories UIManagedDocument creates 
>> and email it (so users can back up their data or share it with others). The 
>> person sent it to me. Below is what I did in the Terminal so you can see 
>> what happens when I try to unzip it. If this doesn’t come through on the 
>> email list with the characters looking correct, I can screenshot it.
>> 
>> This is one of the data files that was created on iOS 10.2 and then won’t 
>> open now on an iOS 10.3 device. It appears the directory name and zip file 
>> name do not match and it won’t unzip correctly. It does create a directory 
>> but the directory is empty instead of containing the StoreContent and 
>> persistentStore files. The zip file is 34KB so it may or may not actually 
>> have the data in it.
>> 
>> $ ls
>> إعلام.zip
> 
> 
> It is probably worth noting that the first Arabic character in the above 
> filename (i.e. the one that appears on the right, adjacent to the period) has 
> a canonical decomposition, as per this line from UnicodeData.txt 
> (http://www.unicode.org/Public/9.0.0/ucd/UnicodeData.txt 
> ):
> 0625;ARABIC LETTER ALEF WITH HAMZA BELOW;Lo;0;AL;0627 0655;...
> 
> That is, in some cases this character 0625 (UTF8: D8 A5)  will be converted 
> to the sequence 0627 0655 (UTF8: D8 A7 D9 95).
> 
> This decomposition was introduced in Unicode 3.0. If there are processes that 
> use decomposition according to Unicode 9 versus Unicode 2.x, or processes 
> that don't decompose versus ones that do, then the filename bytes will be 
> different.
> 
> - Peter E
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/witness.of.teachtext%40gmx.net
> 
> This email sent to witness.of.teacht...@gmx.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: why use extern "C"

[Uli Kusterer]

On 7 Mar 2017, at 17:45, bigpig  wrote:
> I see some code like this in iOS project:
> 
> #ifdef __cplusplus
> extern "C" {
> #endif

Others have mentioned what this code does, but I think it'd be useful to 
provide some background why this is needed:

In C, functions are distinguished by name. A function named "min" must take the 
same parameter types wherever it occurs in your program. There may be no two 
functions with the same name.

In C++, both the name and the parameter types are used to distinguish between 
two functions. You may have several functions that have the same name, as long 
as they take a different number of parameters, or take parameters of different 
types.

However, under the hood, both C++ and C are compiled to machine code. And that 
only supports a single function with the same name, and doesn't know about 
parameter types. So what the C++ developers did to make this behaviour possible 
is that they changed the names for functions. Every function contains a few 
characters at the end of its name that indicate what types its parameters have.

That way, the two functions actually have a different name to the assembler, 
but there is a rule the programming language can use to generate the actual 
function name based on the name and types it knows. This is what is called 
"name mangling."

However, this is something only C++ does, and only C++ knows about. Name 
mangling is fine when you are only using C++, but when you want to make C++ 
functions available to C code, you need to tell your C++ compiler not to mangle 
the function names so C will be able to call them. This is what 'extern "C"' 
does. It turns off name mangling for the functions between the "{" and "}".

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Printing questions

[Daryle Walker]

I like composing controls and such over coming up with new views. This 
frustrates me with printing, though, since it’s based on making a view, and 
making sure that is page-cuttable. I made RTF-export for my app in the first 
place because I thought there was an easy conversion to printing.

Poking around Stack Overflow, I realized that the view to print can be an 
existing class. I could couple the document-data-to-NSAttributedString 
operation I already wrote with a NSTextView to make something that a 
NSPrintOperation could use:

> override func printOperation(withSettings printSettings: [String : Any]) 
> throws -> NSPrintOperation {
> // Copy the message to a string to print.
> var messageString: NSAttributedString! = /* … */
> 
> // Create a view to visualize the message string.
> var info = self.printInfo.copy() as! NSPrintInfo
> info.dictionary().addEntries(from: printSettings)
> 
> let view = NSTextView(frame: info.imageablePageBounds)
> view.autoresizingMask = [.viewWidthSizable, .viewHeightSizable]
> do {
> view.textStorage?.beginEditing()
> defer { view.textStorage?.endEditing() }
> 
> view.textStorage?.setAttributedString(messageString)
> }
> 
> return NSPrintOperation(view: view, printInfo: info)
> }

I hope it’s a nice first try, but I have some concerns.

1. I also added an “Export as PDF…” menu item, which uses the save-as-PDF 
default action. I guess it calls my code, but the docs for 
“NSDocument.pdfPrintOperation” say I should use a separate print-information 
objects for PDF mode. Does the default code take care of that already? Or do I 
have to figure out somehow if I’m in print-to-PDF mode or regular print mode 
and change the initialization of “info” above to be “self.pdfPrintOperation” as 
needed?

2. The RTF files I saved with the conversion operation have wrapping when 
viewed through QuickLook. But the print-outs don’t do that; they do wrap, but 
the limit is past the page margins so I lose part of the text. How can I set 
the wrapping-mode/margins correctly.

3. Are there any other (subtle) problems with the text-view code, since I just 
took it from Stack Overflow?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com