lacerto

Yes, really odd. I tested first resetting Strong character style and replacing with bold tags, and then afterwards applying paragraph tags, and the seemed to work, so it seems you first need to deal with character formatting (and remove actual formatting and character styles), and apply paragraph styling only after that. But it is awkward to to be afraid that this breaks at some point nevertheless and causes massive errors.

I do not know; probably there is a way but I have no idea how deep you need to go to crack the system behavior, and as the problem is fixed (for me at least), and I only get the designed minimum of five Notos now in Affinity apps, I am not interested in going further. It was late, and I expressed myself poorly above. I meant to say that I think that the problems related to Noto (or things like not being able to show e.g. Seravek and other so called Document support fonts available publicly in earlier OS versions), are, IMO, not results of Serif doing anything their own way. I think that this behavior is “by design” of Apple, and dependent on OS and user history, but just backfires, and as is typical, the (l)user “does not need to” [= cannot] be directly in charge, to be able to easily correct the problem. Accordingly, that the OS suddenly starts to behave in a way the user wants to, and apps start to show plain vanilla OS font enumerations without burden of history, is a kind of a miracle, caused by playing around a while in great wise Font Book. I mean: I did not do anything at all in Affinity apps, or even in Finder, to get it work. The “own font management” kinds of solutions that we see e.g. in VectorStyler and Adobe apps, are results of apps deliberately enumerating fonts hidden by the OS. In these apps, it also means that you get the long Noto lists (unless you choose to create your own lists and hide them)-- and still fully expectedly continue to get them after doing something like I did in Font Book to get plain vanilla lists shown in all Affinity apps -- but also that you get fonts like Seravek, even if you do not have history of using these fonts earlier in these apps, or documents created by them. I may of course be totally wrong, and just do not understand how the OS is designed to work. But this thread (and this is not the only one related to listing of macOS system or hidden fonts) shows that I am not the only ignorant user who feels frustrated.

As an ignorant Apple user, did I accidentally touch myself? The problem appears to be OS dependent in a way that the result of an API call for available (installed) fonts varies according to user/OS history.

This was mentioned in the IngramSpark instructions (link above) both for b/w and color books on pages 8, 9, 10 and 11. Whether inner bleed can be there is much up to printer's preferred workflow in these kinds of jobs, but it seems that they are often so automated that if the bleed setting is not according to the specs, the job might actually get incorrectly positioned and printed. A facing pages layout itself does not need inner bleed because there will technically never be visual gap as a result of misregistration (because of the binding, or because the abutting page printed on the same sheet needs to be limited to exact page boundary on the binding side, so that nothing gets "bled" over the page edge. In jobs where pages are not bound side by side there naturally needs to be inner bleed setting, as well. Most often the printer's imposition software trims unnecessary inner bleed, if it is included, but IngramSpark specifically warns in the referred instructions that unnecessarily added inner bleed may result in wrongly positioned printout.

I do not think there were changes between the versions. One possible workaround could be using a rectangle with an opaque fill with a specific ratio and then placed in the back of the image upon which selections need to be made, and then copy pasting this rectangle and resizing and moving it as needed. Filled shapes can be used to create pixel selections, e.g. to crop faces from a group photo, so that images have the same ratio. If shortcut keys are used (Ctrl + C for copying the rectangle with correct ratio, then Ctrl + V (resize + positioning), Ctrl + Shift + O (make pixel selection), Ctrl + Shift + C (Copy flattened), Ctrl + Alt + Shift + N (Create from Clipboard), for each area that needs to be clipped, it could ease the pain a bit: clipping_fixed_ratio.mp4 .

Hi Valliard, and welcome to the forums. This is really quite confusing. I'll try to explain the reasoning behind IngramSpark instructions. a) Recommending PDF/X-1a:2001 or PDF/X-3:2002 basically means that they want a file that does not have live transparencies (e.g. objects or layers that have blend modes or opacity values). Whether these standards are actually required and checked (so that if requirements are not met files are rejected) is not clear, but I doubt it. Affinity apps cannot produce exact these standards, but instead PDF/X-1a:2003 and PDF/X-3:2003, but the differences are minor and irrelevant in context of the kind of production needed in your design. The instructions are basically created for someone working with e.g. InDesign. The workflow and production with Affinity apps is a bit different. b) Mentioning "Grayscale" as color space refers to books that are going to be printed only by using black ink, so text needs to be pure black, and possible images in grayscale color space. You can achieve this in Affinity apps both when working in Grayscale/8 or CMYK/8 color space, but considering that they also mention PDF/X-1 or PDF/X-3 (which automatically flatten any transparencies in the design, and which are also the only automatic methods of flattening transparencies without total rasterization of PDF within Affinity apps), it is best to choose CMYK/8. [Using PDF/X-1 or PDF/X-3 based methods will convert all native colors to CMYK in Affinity apps, and Grayscale based color values, internally handled as RGB, would become four-color-black values.] c) Mentioning that ICC profiles should not be included basically means that all colors need to be resolved, and the output of the production PDF is DeviceCMYK or DeviceGray so that no embedded color profiles are needed to calculate the final gray levels. When you export using PDF/X-1a:2003 or PDF/X-3:2003 within Affinity apps, you will get that kind of a production file. This means that you should: 1) Create a document using CMYK/8 color space. You can use the default U.S. Web Coated (SWOP) v2 profile unless the printer recommends something else. Use 3 mm bleed on outer edges (but set Inner bleed to 0). 2) Make sure that you define color for text by using CMYK color model (in the Color panel), so that values of C, M and Y inks are 0, and only the K ink has values (from 0 to 100%). 3) If you have images, they need to be in grayscale mode, or if in RGB mode, need to have K-Only button turned on so that the images are interpreted as grayscale images. Grayscale images automatically turn on "K-Only" mode when placed in the document. 4) Export using PDF/X-1a:2003 or PDF/X-3:2003. If you have facing pages layout, make sure that you export "All pages" rather than "All spreads". Remember to include bleeds. Note that when you make selections in the "More" options, the preset label "PDF/X-1a-2003", etc. will be deselected but just including e.g. bleeds does not mean that your export would not be based on the selected standard. EDIT: There is one caveat when using PDF/X-based export methods within Affinity apps: if you intend to place PDF files in the document in the default "passthrough" mode, there is a risk that these files will be rasterized on export (in this case, it is safest to export using PDF/X-3:2003 and make sure that all placed PDFs are produced using PDF/X-3 based export method).

Yes, it can. I do not know Vectornator, either, so I do not know if there is a specific option (e.g. skip Noto, skip non-Western fonts, skip CJK fonts, etc. etc.). But it is not complex to skip user-defined fonts when enumerating the fonts for menu lists. In this case, the routine could basically check if the listed font is visible in the Font Book (or if it is returned because of being a legacy font that was visible in an earlier version of OS; but I have no idea if this is readily available or requires some extra code and knowledge). As for difference to VectorStyler, I think that their intention is to list all available and hidden, supplemental etc. fonts. In addition to Noto and all its dozens of styles, it means that it can also list e.g. 10 Seravek styles that are available to apps that know that these fonts are included in the OS even if hidden (many other apps, including Adobe ones, can list them, too). VectorStyler has also capability to make disk fonts (not installed on system) available in app menus, including PostScript Type 1 PC fonts and has a kind of Font Manager of its own, so it has means to create meaningful lists (even if it seems that the feature still has some bugs). But it is really a kind of a power-user's app, overwhelmingly complex.

So, it seems that earlier OS versions listed more of them than Ventura does, and this behavior is somehow carried along OS updates (for me on this computer, starting from Big Sur). Which then points to existence of obsolete font caches that I happened to get rid of when fiddling with a user-created Collection.

I think PixelPest mentioned Vectornator Pro. I assume that what was meant is that enumerating fonts should be in the hands of the developer so that irrelevant fonts can be skipped. If defaults are used, or library functions that are not customizable, you get bulk lists. But as shown there seems to be more than just this, some old caches, etc., and also anomalies related to OS updates (e.g., so called Document support fonts that were revealed in earlier OS versions but are now hidden; or system fonts that were formerly distributed as static fonts but are now distributed as variable fonts).

They are not shown on Ventura, either, and now they are not shown in Affinity apps, either, so for me Affinity apps now list fonts as I expect. They do show those five that also show in the Font Book as locked fonts (show a lock icon, and an error message if you try to touch them) that cannot be moved or inactivated. Before this change, Affinity apps behaved similarly as in your case when they show Armenian and Zawgyj versions of Noto. Those dozens of other versions of Noto never showed in Font Book. All removals and inactivations I have made have been made within Font Book, so I have not done anything in Finder.

When you export to PDF, uncheck the "Use advanced features". Whatever it does, CorelDRAW has never liked it.

Yes, this message is shown if you try to remove the locked Notos (I think there are five), at least if you try to remove them from the system library. But when I copied all fonts from the "All fonts" category to the newly created "My Collection" collection (including inactive ones), and then removed them [the Noto fonts] from "My Collection", and afterwards also removed the whole "My Collection", the superfluous inactive (but unlocked) Noto fonts disappeared from Affinity font lists. I think that what might have happened is that when I create a collection and then add fonts to it, the physical fonts are actually copied somewhere on my personal library (rather than just referenced; at least creation of the collection took some time). If I then remove these fonts in the collection that I created, those font files are deleted from my personal library. as well. Perhaps the font cache got forced to be recreated at that point for the whole system and the status of Noto fonts (uninstalled but available) got updated. I have no idea how Apple handles fonts so this is just guessing.

It works ok if the white space does not have bold character style (if it does the second <b> bracket will include the space). If it does not, I get this: <b>an</b> <b>te</b>

S That's odd. On my system (Windows 11), the word wild character based search works fine both on version 1 and 2: reget_search.mp4 I have not tested this on macOS yet. [EDIT: I now have, and the behavior is identical there, both in v1 and v2.] But as said, version 1 behaved similarly with character wild character so this is not a new issue (unless introduced in version 1.10.6).

An odd thing happened. A few minutes ago I had all those Notos listed in Affinity apps. Then I created a collection that I named as "My Collection", and copied there (within Font Book app), all fonts from the "All fonts" category. I then removed all "Noto" fonts from "My Collection", and then deleted "My Collection" (I did the whole thing just to see if VectorStyler could then use just "My Collection" to restrict the font list, but it did not even show the whole collection). After that, all Affinity apps, both version 1 and 2, only show the five Noto fonts that are locked, so the long list of available but not installed fonts are no longer shown! I am on macOS Ventura on a computer that had Big Sur as the first OS, so perhaps something has changed along OS updates but just old font caches now got refreshed (but why, there does not seem to be any logic). Anyway, I have restarted and the situation has stayed, so perhaps some kind of a solution? UPDATE: The Noto fonts still reside where ever they have always resided so e.g. VectorStyler (that also includes hidden Document fonts like Seravek in font lists, while Affinity apps cannot show them on Ventura) still lists all those hundred + Noto fonts. It is just that now non-locked Noto fonts are no longer listed in Affinity apps (so this is basically in line with non showing fonts like Seravek).

I think you need to specify search clause as: The behavior seems to be same in version 1, so .* seems to show the instances but does not seem to work when replacing (or focusing).

It is complex. On a personal level (or as a family company) we have saved roughly EUR 15,000 during a decade or so staying (mostly) out of the subscription model but have now had the EUR10 per month basic Photograph plan -- which I think is a bargain considering what is included -- active for a couple of years. This has also required sticking to legacy software in addition to spending something on supporting and "plan-b" tools. But now Adobe has made a swift move (or relatively so, considering the size of the company and how strong they have been on desktops), and seemingly disruptive one, to web-based creation, which they seem to be on a way to integrate with their costly pro (still mostly desktop) tools and workflows, while at the same time offering a strong "freemium" plan. Oh yes, a plan it is, and it is clear that anyone stepping on this path will be tempted or forced to pay "a bit more" in the long run. For old school like me this means new school, but I mostly welcome the change, knowing well that this is not something that is going to make old workflows useless or requiring us to subscribe to full plan. So we are trying to keep "our plan". I can fully understand the original post and users trying to completely avoid Adobe. But it is good to stay awake and open to changes -- if price is the only consideration, there might be temptation for many to go back on the "dark side". I sincerely hope that alternative paths continue to exist also in the new brave world of graphic design.

Wow 🙂 Unfortunately we all know that this is not true, but more generally, I think that the article is based on wishful thinking. Adobe not only purchases competition "away" but integrates it to become stronger. The writer of the article did not even mention (partially free) Adobe Express or Android (much neglected creative) platform and d/l figures and competition there... I think the life has become significantly more difficult for the competition during the last three years or so, and the recent developments are something that are especially targeted for private and hobbyist -- and young -- users. I agree that monopoly is a totally bad thing, but sadly it does not appear that the giant is suffering of any kind of midlife crisis or loss of vision...

Curly quotation marks on Windows – if the keyboard has Numpad, then: ALT + 0147 for “ ALT + 0148 for ” ALT + 0145 for ‘ ALT + 0146 for ’ If not (like often when using laptops), use e.g. free utility like Autohotkey (which starts on my system by pressing WinKey Z), and remap the keys. I use Alt 2 for ” and Shift Alt 2 for “ and WinKey 2 for ’ and Shift WinKey 2 for ‘ and, because in Finnish we do not use different opening quotation marks (so if I need them e.g. in English, I use the Shift modifier key). +!2::Send {U+201C} ; double quotation mark 66 !2::Send {U+201D} ; double quotation mark 99 +#2::Send {U+2018} ; single quotation mark 6 #2::Send {U+2019} ; single quotation mark 9 Obviously alternative definitions would be required for other national variations like German and French style quotation marks. Autohotkey has the benefit of being able to remove the scripts from the memory and revert to the default (or an alternative) key mapping.

Ok, I see [I made a wrong assumption as I have very little experience of Apple scripting, and UI scripting was mentioned]; personally I have found working with scripts and object models quite meaningful and straight forward, but whether this is useful much depends on the workload and how much you need to repeat a specific task. Adobe file formats are indeed different from each other, even if e.g. InDesign and Illustrator share much of their object models. The recent versions of InDesign and Illustrator seem to be able to share content via Clipboard more extensively (they always have, but with limitations). Personally I have not found integration of content from Adobe trio problematic, and I like to keep file sizes small and creation of production files simple and predictable.

I opened the text in Xara Designer Pro and noticed that each space character has an exceptional positive kerning value as if width of 1 zero-width space having kerning factors like 195 ems/1000 etc. [with a trailing character]: fontspacing_issue.mp4 As the font is embedded by PDFLib, this really seems to be partly an export issue, and of course also import issue, if Publisher cannot read what it has initially written. Publisher shows absurd tracking and kerning values for all imported text from this file. But what could be the reason to encode spaces this way, in the first place [EDIT: Or perhaps full justification is always created this way when producing a PDF]? UPDATE: Opening in Xara some other PDF files shows similarly handled spacing in all files, so this indeed seems to be the way spacing is achieved when embedding fonts. When opening these files in Publisher, they show standard ("automatic") kerning and tracking values so it seems that for some files mapping of embedded fonts to installed ones, and conversion of PDF spacing to standard spacing just fails.

I am not sure if Adobe object models are somehow crippled on macOS and AppleScript, but I think the complete object models are available also for Javascript. On Windows you can use Javascript, VBA or VSTA (VB.NET or C#). Anyway, you have the complete app object models accessible to any app supporting Javascript, VBA or VSTA scripting, to e,g, export to any format supported by object models. E.g., in VBA, path related PS interface looks like this: ...and the equivalent Illustrator interface like this: You can also run any PS and AI action from within scripts so programming can be facilitated by recording actions in both apps and using them. There are most probably ready-made scripts on the Internet for these kinds of tasks to get started with. A non-programmatic approach worth testing -- if Adobe apps are still available for you -- would be importing images with paths to InDesign and then saving as IDML. Affinity Publisher that opens an IDML file can then use ID created TIFF transparencies, which could be saved or copy pasted to be used in Affinity Photo: EDIT: The image above was mistakenly created using the image alpha channel (which often exists in an image containing a path). Below is a screenshot where InDesign creates a Clipping path using a Photoshop path included in the image, and where an IDML containing such clipping path is subsequently opened in Affinity Publisher (to be subsequently saved in format that can be opened in Affinity Photo, if so liked):

More generally I guess there are multiple standards and house styles, and no "objective" rules. Each different style can have good reasons for using them. EDIT: One good point for just using the app-provided drop-cap feature with all its restrictions and doing the best that it can offer is if the publication will be available also digitally, since custom drop-cap creations normally degrade accessibility (e.g., reading or searchability of the text is disturbed by having the initial in a separate text frame, or parts of text in some other way detached or separated from the body text (even if just with forced line breaks and extra spaces or tab characters).

In OP’s case, the actual reason why the Affinity created SVG version takes more disk space than the one created by Adobe is that the former has 1,010 curve nodes each of which is described with accuracy of 3 decimals, while the Adobe one has 969 nodes, which are described in accuracy of 2 decimals max (the accuracy is user-definable at export time e.g. in Illustrator). Additionally, the Adobe version describes the drawing instructions whenever possible as a series of vertical or horizontal shifts using variably absolute and relative coordinates, which saves space (since only X or Y needs to be described). E.g. one short path (character shape forming the capital letter “H” in the logo) is described (spaces added to separate the commands) as one absolute moveto and then 12 absolute lineto commands before closing the curve. <path d="M89.152,21.792 L89.152,42.201 L87.141,42.201 L87.141,32.657 L75.039,32.657 L75.039,42.201 L73.055,42.201 L73.055,21.792 L75.039,21.792 L75.039,30.875 L87.141,30.875 L87.141,21.792 L89.152,21.792Z" style="fill:rgb(99,100,102);fill-rule:nonzero;"/> The Adobe created file describes the same path as follows (drawing the shape clockwise starting from the top right node): <path class="a" d="M89.15,21.79 V42.2 h-2 V32.66 H75 V42.2 h-2 V21.79 h2 v9.08 h12.1 V21.79Z"/> So the Adobe version uses 62 characters spaces excluded to give drawing coordinates for the letter “H”, while Affinity uses 183. The latter is more accurate (it seems that always given with 3 decimals), but it also uses a pair of coordinates where only X or Y is needed, and repeatedly describes the same fill color and rule for multiple paths. In the Adobe created file the fill colors are described as class properties so they do not need to be described repeatedly for paths using the same properties. Fill rule is given only if needed. The SVG code in these files is not specifically created to be human readable so both encoding styles save space by not adding unnecessary space between commands and coordinates, and do not wrap the long coordinate lists. I would say that anyone experienced with SVG can read both kinds of path descriptions without problems. For the Adobe version XML formatter and a proper editor is needed, but excellent editors are available for free, as are XML formatting extensions/plugins and syntax colorizers and anyone in frequent need of having a look in SVG code should really get one.

It is all structured so there is not much "throwing" if you have e.g. XML Tools extension installed in Notepad++ or Visual Studio Code: xmlformatting.mp4 Also, Affinity generated code takes pretty much as much disk space linearized so the compactness of Adobe code is not achieved just by linearizing.