fde101

There is a setting, both on the desktop version and on the iPad version, for whether the icons should be colored or mono. On the desktop, the icons you mentioned honor that setting, but on the iPad, they seem stuck on mono whether the setting is for color or not. Some users would have trouble with the icons being color because it can throw off color perception of the document itself and in a strict color-managed environment mono icons are definitely preferable, so it is critical to keep the option for the icons to be in mono, but for amateurs and other users who aren't as concerned with color accuracy (and to be clear, some professionals can certainly fall into this category as well depending on the nature of their projects), I agree it would not be bad to sync this behavior with that of the desktop versions. It is not clear to me why they would give the option for color icons on the left toolbar on the iPad but not on the others.

If you follow through with your analogy and make it fit the way global layers would work, it would need to be the case that every hospital in the world had the same number of floors and laid out their floors in the same way and that if one hospital decided to repurpose one of their floors, then every hospital in the world would repurpose the corresponding floor in the same way at the same time. Each hospital may have floors that are different shapes (master pages) and they may have different sets of rooms on any given floor (page content). I'm not too sure that actually works. 😇

If the frames are both on the master page, can't you just hide the undesired one on the master? Additionally, if there is more than one frame per language, couldn't you color tag them and use those to hide the frames via the States panel?

can be handled using the 3rd-party data mechanism of the IDML format. Adobe documented a method for plugins to include their own data in the IDML file, and specifically indicated that if the data is for a plugin that is not installed when the file is read by InDesign, it would simply be dropped / ignored when importing the file. If the Affinity apps stored their unique data (that which is not represented by the IDML format already) in the form of plugin data for a plugin which does not actually exist, they could recognize that data and use it to recreate the unique Affinity stuff when importing the file, but InDesign would simply ignore it. That way a single exported IDML file would offer the flexibility to be imported by any version of the Affinity software that supports IDML import (anything older than what recognizes the "plugin" data would simply ignore it, while versions new enough to recognize those properties could recreate the original Affinity document to the extent that the properties are recognized by that version), by InDesign or QuarkXPress (which would ignore the Affinity-specific properties as being data for an unrecognized plugin), as well as being used by 3rd-party utilities for processing the text where needed - killing three birds with one stone.

Oddly enough IDML export, if correctly and fully mapped to IDML import and extended with all of the features of the Affinity apps, would actually be useful for the same reason it was originally created: people using older versions of the Affinity software receiving documents from people using newer versions. If someone saves a document in 2.8 and sends it to someone running 2.7 they can't open it (hypothetical future product versions). If IDML export were available, they could use the same trick that the format was originally created for, export the file as IDML, and the user with 2.7 could then import it. This assumes that the Affinity apps can correctly interpret their own output, which is a more likely outcome than is the notion of Adobe products (or QuarkXPress) correctly interpreting all of the output of the Affinity products.

I don't think I would trust to read that far into the marketing blurb. Canva is more of an amateur graphics company, as hinted at by the fact that they want to empower "the world to design" rather than giving "designers the world" - their focus is not really on professional designers but rather on people who are not professionals but still want to design in spite of that; the "professional" workflows enabled by IDML, even with the acquisition of Serif, are probably not too high on their radar. The IDML format was originally created for moving documents from one version of InDesign to another (evidently Adobe couldn't quite get cross-version compatibility of their native format right so they created a separate format as a workaround), and it is something of a hack that other applications started working with the format. IDML as an interchange format outside of the Adobe ecosystem is not really a good solution for design interchange, it is simply the one that we have that maintains a larger portion of the original properties - a more stable format is PDF, but you obviously lose a lot when you use it, due to the nature of what PDF was designed for. Both formats originated with Adobe and they were not exactly trying to improve life for their competitors; even with IDML import things should not be expected to translate completely into a different application, and the same would be true in the other direction.

How is that even remotely relevant?

If you saved the document in 2.6 you probably won't be able to open it in 2.5.

JavaScript is a mess. It isn't fully aligned with anything. Different people have built on it over time in so many differing ways that there is very little coherency to the language. The need to maintain backward compatibility means that even when people have tried to "clean up" the language and enhance it in various ways, they ended up creating mutually incompatible versions of the language which are all "official" in some capacity and thus one bit of JavaScript code might not play nice with another even though any given runtime environment would still need to support both.

No it isn't. Python would not exist without machine language. ... may have been well-intentioned but was ultimately a bad one. Which may also be well-intentioned but can be misleading if done the wrong way, as this was. Indentation is visually helpful, but it is not enough on its own. Even in a "reduced" state there can still be a large amount of code for a given project, and if you have many levels of indentation then suddenly drop back several levels, such that the code is several screenfuls down, it can be difficult to follow where things line up. Having an "end" marker of some sort to count can make that a lot easier. ... as am I. I hate it. Yet another reason to view AI with skepticism. We didn't really need another one, but it doesn't hurt. Technically not always. Many implementations actually do "just-in-time" compilation and translate large parts of JavaScript into machine language to execute natively on the processor. There are Python implementations that do essentially the same thing. There are also Python compilers that perform static compilation and translate Python into machine language, just like most native languages would be. Apple's Swift language has a "repl" implementation (try "swift repl" at the command line on a Mac with the development tools installed) which compiles and executes Swift code in "real-time" as you enter it. There are ways to use Swift as a scripting language, in spite of the fact that it is compiled behind the scenes - the Swift compiler is quite... swift. Swift is not a great language either, but at least it delimits blocks somehow (sadly following primarily in the footsteps of C with its hopelessly cryptic syntax), and thus is at least preferable to Python.

Those commands do not actually rotate the image in the document, they only rotate the view on the screen. When exported or printed the image will have the same orientation as where it started.

Only font glyphs are supported for use as bullets. They are entered in the "Text" field under Bullets & Numbering when editing the paragraph style.

As a workaround to a bug. Long-term the solution to that is for the bug to be fixed rather than worked around. The solution @PaoloT was hinting at (which is really for a different scenario) would also cover this if needed, if it were available, but as a workaround rather than a fix. Thanks for pointing that out.

This is a duplicate of a duplicate request: There is also a related request which is *almost* the opposite:

@PaoloT seems to have substituted ".jpg" for ".afphoto" as this reply is describing something approximating the type of proxy workflow that is common in professional video editing. I suggest looking at the way professional video editing software supports proxy workflows for ideas related to that. A proxy workflow is normally used to go from low quality to high quality so that editors can work with low-quality but fast-to-process / small-to-store files then substitute the high-quality ones toward the end of the project. In the OP, @Gianni Becattini is describing a rather different problem and is trying to produce smaller PDF files. I would suggest that export options for the PDF file to help better control the output of embedded files might be a better choice of request for this, as it also helps to eliminate the need to export the .TIFF files in the first place. For example, an option to limit the resolution, color depth, etc., of embedded raster objects; an option to rasterize layered raster images into a single object in the PDF output; etc.

@Red Al, there have been numerous threads discussing these things in the past, so you might want to search for those to see what has already been discussed about this. Publisher documents are the same as Photo and Designer documents; the color support is shared by all three apps because they can directly read and modify each others' documents. It would not be practical when working on a photo to use global colors for everything, so in order for the documents to work well in Photo, Publisher needs to support non-global colors as well. You already can - using the "Make Global" command in the context menu. It needs to be in a document palette, however, as only document palettes may contain global colors; also, if the color was already used in the document, this will not "link" the existing use of the color to the palette entry, as it was not a global color when it was used in the document. This is wrong. Again, only document palettes may have global colors. Modifying a color on an application or system palette will have no effect on the colors which already exist in other documents (or even in the current one). This concern is a non-issue.

And rob the OP of the opportunity to practice using the search feature and thus be more familiar with it for next time? Whatever... take your pick (though three of these are also redundant):

Hi @jose74, welcome to the forums! In the future, please search for existing threads requesting a feature before posting new ones and add to the existing ones instead when present. This is a duplicate of an existing request.

Many, many things are still printed; to name a few: People still buy books, including printed ones. Labels for packaging. Menus for restaurants Handouts/fliers for various events Maps for use in the wilderness / camping / hiking, etc., where power might not be available or reliable Additionally, digital media still needs to be designed before someone can experience it.

If this issue is specific to text, then one option is to make the text tiny, rasterize it, then scale it up.

Agreed, "now" lagging behind doesn't make sense, since they have been lagging behind in some capacity or another from day one. Both of the other products have been around much longer and have had more time in which to develop. That doesn't mean the "newcomer" is doomed to fail or to always be behind - there are likely many users for which the Affinity products are a better choice for one reason or another, even ignoring cost or pricing model. Different types of projects, different tools that work better for them.

Yes, for sure.

I am familiar with a number of programming languages, scripting and otherwise. I have an almost irrational hatred of the way that Python uses indentation as part of its syntax, and accordingly have zero interest or intent of ever wasting my time learning that or any other language which suffers from this same design flaw. It is bad enough that Makefiles use tabs as part of their syntax. I don't like the C-like languages either, and JavaScript is an absolute disaster of a language, but I am more willing to put up with those when necessary than to put up with Python and its ilk.

As has been pointed out a few times, the Scopes panel has the same issue, in addition to being much too small at its fixed size.