thetasig

If the EXIF and other metadata is exploited, the user could decide which field to use, where to place it and might even combine fields to attach to a single photo. For example: Metadata Cloud.afpub

Thanks, Walt. Yes, seems that is the case. I still would love to have my applications match up with the system defaults in that regard. As it is, I can't really change any of them, especially the Resource Manager and Lightroom. Yes, it is possible, though tedious, to capture the system list and then put it into some other application that can sort alphabetically, but having to do that many times over can really eat up a lot of time. The Affinity User Interface should do that by default (system-dependent) IMHO.

I'm not sure why this is the case, but if you compare, say, the Mac Finder list of resources (photos, in my case) with Lightroom's list of photos and with Affinity Publisher's List of the Resource Manager, the sort order of the Mac and LR match, but the Resource Manager has a different order. I'm not totally sure, but it seems to be the way leading numbers on the names are sorted. Mac and LR sort by the numeric value, then alphabetical, Publisher sorts by, I believe, hex value - or by character value, then alphabetical characters. Thus, "007" comes before "6" in Publisher, whereas it's the reverse on the Mac and in LR. This plays havoc with the user's ability to cross-check and validate Publisher resources against system lists. Can't we have a match of Publisher's sort (everywhere, e.g., Resource Manager, Index, etc.) with the system it's installed on? Thanks! See example screenshot.

Thank you, Walt. I did get it to work. However, I found that using Scaling, anchor to page, or anchor to spread all moved objects around on the pages - losing any "centering" I had used between objects and centering to the page. This meant that, for example, background images (full spread or full page) would overlap into the bleed (or not abut the bleed as originally done) instead of staying within the boundaries. I performed a manual change back to what I wanted, but maybe this should be looked into. What I would expect is that "scaling" would automatically scale objects larger or smaller AND keep them in a relative position on the page and/or spread. Am I expecting too much?

Thank you, Walt. Is it possible to try out the Beta for that purpose, then back down to the current released version?

One compelling reason to provide an export of the Resource Manager list is to make a list of photographs used for the purpose of submitting them to the (U.S.) Copyright Office. Not all the photos in the linked File Folder may be used, so that folder may not be a good choice to use to create the list. Ideally, the export will go into a CSV (for use in a spreadsheet) or XLS type of format or even PDF). I'm facing that problem now and have over 800+ photos that I have to manually sift through using the Resource Manager as a basis (eyeballing the list is overwhelming).

I just used the Spread Setup to change the document specifications. I used "scaled" for All Pages and made the page width a few points less wide. And changed margins a bit. All of the document pages changed to match. However, the master pages did not change - so that leaves the "section names" and "page numbers" (that are at the inside corners of the margins) not displaying correctly on all of the spreads. That is, the recto page (the spreads are now less wide than the masters) shows page numbers and section names too far to the right. They are "objects", correct? I have 4 masters and each spread/page has only a single master applied. So then I displayed the first master page and attempted to change the document size - AFPUB froze and stopped responding. Would appreciate help in getting this done - the object is to make the pages slightly less wide in preparation for uploading to a print shop - to meet their specifications for page sizing, etc., AND to get the masters to change to match. And, ideally, the objects on the pages will scale a tiny bit to accommodate the less wide pages.

You may already know about this, but it saved me from losing hard work. Inside the Preferences is a setting for "Performance/File Recovery Interval." This automatically saves changes periodically. During the Beta, AFPUB crashed on me a lot. So I set this to 90 seconds. It took that long to open my large document. Right after a crash, I just restarted AFPUB and it offered to open the recovery file, and the document changes were always intact. It's a setting that I left in place just in case, but AFPUB has been fairly stable since the latest version.

Walt, you are correct and thanks for pointing that out. I am hoping this (vertical position) will be treated as a bug though. I don't think that action is meant to be a "toggle"

MikeW - sorry, our posts collided. That's a great idea. I just checked Zara's descriptions at their site and it seems very useful. There was some talk in Beta about including a future grammar check along with spelling, maybe that can all be packaged together.

Just to clarify, the example file was not exported by AFPUB. It was generated externally by a third party (unknown) and then imported into AFPUB. The hyphen in that file is an en-dash. You are correct, Pauls, it might be very difficult to determine how to handle hyphens as there are at least two variant usages of the en-dash. One is an end-of-line break in a word, which hyphen would be omitted if the word did not fall at the end of the line, and the other are compound words, i.e., "pick-me-up," and those would need to be kept intact. My suspicion is the user would, at some point before or after the import, have to intervene to check each instance and make a choice of what type of dash to use. A simple find and replace would be the easiest way for the user to make any corrections needed, that is, until AI is perfected :-)

Here is the PDF that I imported. Example PDF with hyphen.pdf

To add a little bit more to this conversation, and Walt hit the nail on the head, I will say that the particular "icon" being displayed has several choices hidden until you drop that menu down - then you see the *other* icons for different justification choices. I would have preferred to not hide those behind a single icon, but I've gotten used to it now. Also, there is a vertical position icon - now here is where there is a small bug. If you click it and choose to position to "top" and then position again to "top", the s/w toggles between "center" and "top" (and continues ad infinitum). It's not hard to change it, but one needs to look at the resulting icon to see if it displays the position you really want, i.e., making sure you position at top and not center. I don't have the program open just now to verify, but I suspect that "bottom" and "center" might behave similarly.

I just imported a PDF of a text file. It has the word "representatives" hyphenated (hard coded) at the end of a line: representa-tives. The import worked perfectly. However, AFPUB flagged the word as misspelled. It was underlined in red. I thought "well, that is not misspelled, it's just hyphenated" so I didn't expect the red line. It wasn't until I replaced that hyphen with an AFPUB "Soft hyphen" that it became spelled "correctly" with no red line. I noted that the Soft hyphen is virtual and cannot be selected by itself. Maybe that is why the spell check sees it as spelled correctly. I'm not sure it's really a bug but decidedly unexpected. I wonder if importing en-dashes used as hyphenation might require a different way of thinking to avoid the misspelling.

Thanks Pauls - I'm looking forward to improvements.