Templates not working (at first)

[lepr]

On 3/5/2020 at 8:05 PM, R C-R said:

I don't know why, but in all my apps including Apple ones like TextEdit, even though I have set the preference to "Always," the scroll bars do not appear if all the content of the window will fit into it. I run Mojave but it was the same in High Sierra & (I think) in Sierra. The only thing that always appears with that pref set is the scroll bar channels along the right & bottom of the window, but the scroll bars themselves do not appear unless the content will not all fit in the window.

The thing that you are calling a scroll bar is actually just the knob of a scroll bar, and there should be no knob when scrolling is not possible. The thing that you are calling a channel is the track of a scroll bar. Your "Always" preference is working correctly since the scroll bar tracks are always visible regardless of whether the knobs are present.

[R C-R]

@Wosven, if nothing else please consider this scenario:

• I create a new document in AP or AD that among other things has several text layers.
• I decide I would like to use APub's find & replace feature to change some of that text, so I use File > Edit in Publisher to switch to APub & do that.
• I want to use this document layout as a template so while still in APub I use File > Export as Template to do that.

In your 3 template scheme, which extension should the app use for the template file, the ".aftpublisher" one because it was exported from APu or the ".aftphoto" one because that is the app that I would most often use it with, or perhaps even the current generic .aftemplate one?

There are of course many possible variations of this scenario, each one involving editing a document in more than one Affinity app before using File > Export as Template in any one of them to create the template file, including some that might include opening an existing native format file as the starting point.

So have you given any thought to how would you want or expect your scheme to handle each of them?

[Wosven]

9 hours ago, R C-R said:

My point is this would require the addition of 3 new file formats extensions

And again it's not a problem, and not difficult. There's already datas about version, why not add app info with those? It's more anoying to open an AD or AP file in APub and loosing all the Export persona abilities and settings, or opening an APub book in AP or AD and loosing master pages and facing pages.
That users should apend suffixes or create subfolders to distinguish files or open a file and close it because it's the wrong app isn't good.

That the apps share the same code and the files too, and that we can open a file in the 3 apps is interesting, but it doesn't mean it should share the same extension. And that's why we have 3 different ones for the 3 apps. Why only one for the template type of file?

They manage more important things like bunch of layers, groups, effects, filters, images, or regular expressions, or parsing different complexe xml… Adding 3 instead of 1 extension for a type of file to be processed the same way is nothing, if it helps the end user to reconize which app is better suited to open it.

And don't forget aftemplate files aren't a different file format, it's only a distinguable extension triggering a different action — new from this file — in the Template panel only, that can only display files with this extension, since opening an aftemplate file the regular way is like opening a regular file using the "open" command.

 

13 hours ago, R C-R said:

There is nothing to decode

There's always something to decode or parse, like its own code. perhaps at the core of those files it's xml like used in other apps. And to protect this a protection when compressing it to have smaller files. But I don't mind, if it's working properly.

Compressed xml is common, it's easier to uncompress, read and import in other apps, like we can do with Office xml (docx, xlsx, etc.), or LibreOffice files (zipped folders and xml too), or idml imported in APub. Perhaps one day we'll be able to import epub too since it's the same: folders with html/xml files compressed in a zip file.
Some files are protected while compressed for example, and other aren't.

14 hours ago, R C-R said:

Is it possible you are thinking about creator codes

No, when I talk about magic numbers I talk about magic numbers. https://en.wikipedia.org/wiki/Magic_number_(programming)

• “A constant numerical or text value used to identify a file format or protocol; for files, see List of file signatures ”

[R C-R]

19 minutes ago, Wosven said:

It's more anoying to open an AD or AP file in APub and loosing all the Export persona abilities and settings, or opening an APub book in AP or AD and loosing master pages and facing pages.

I am not sure I understand what you think you would loose by opening a native format file in a different Affinity app than the one that created it.

It is true you can't use the AD or AP Export persona while in APub but should the need arise for anything you can't do from APub's File > Export window, you can use File > Edit in Photo or File > Edit in Designer for that (or just open the file directly in either one). So for example you could add slices for all or some part of selected APub's pages (including master pages) & those slices will be added to the file on the next save, so at a later time you could open the file in AD or AP, switch to the Export persona & they still will be there.

You can also open any .afpub file in AP or AD & still have full access to its pages, again including master pages, & even change document properties like facing pages or the image replacement policy. (Like I said, this also works with the iPadOS versions of AD & AP.)

So sure, it is much easier to use whichever Affinity app offers all the tools you want to use on an Affinity document & does so in the most straightforward way, but nothing in the document is lost if for whatever reason you want or need to use several of the apps to work on it.

1 hour ago, Wosven said:

No, when I talk about magic numbers I talk about magic numbers.

OK, but from what I can tell all files saved in the Affinity native document format (including templates) use the same short (16 character) magic number prefix & there is nothing else in these file that would indicate which app created it. Obviously, there is some guesswork involved because they do not document the native file format but I am reasonably confident this is correct because I have spent a fair amount of time running various tests, at least a few of which I believe would show different results if I was wrong. So far, nothing has.

(Side note to the staff: I am not trying to reverse engineer the format. Originally, I just became curious about it because I was hoping there was some way to tell if an .afbrushes file contained vector or raster brushes & part of that was comparing the contents of various native format files to one another.)

Anyway, I think the developers have spent a lot of time working out the considerable complications involved in creating native file formats that all three apps in the suite (& any new ones they are considering adding in the future) can use without the need for any conversions or data loss, across three families of operating systems, & that what they have decided on is the best compromise for this point in the development process. Maybe that will change in the future but for now it is good enough that I think their priorities should remain elsewhere, most particularly in fixing all the bugs in the 1.8.x versions of the apps.

[Wosven]

4 hours ago, R C-R said:

• I create a new document in AP or AD that among other things has several text layers.
• I decide I would like to use APub's find & replace feature to change some of that text, so I use File > Edit in Publisher to switch to APub & do that.
• I want to use this document layout as a template so while still in APub I use File > Export as Template to do that.

In your 3 template scheme, which extension should the app use for the template file, the ".aftpublisher" one because it was exported from APu or the ".aftphoto" one because that is the app that I would most often use it with, or perhaps even the current generic .aftemplate one?

The logical step is to switch back to the original app and export the template from there. If you needed more APub features for this document, you would have created it from the start in APub, and used the personas to use part of AD or AP features that are disponible in them.

If you used the wrong app creating a document, nothing prevent you yo open it in one of the other apps and saving it with this app's extension. I do this when I work on an image in AP and end up deciding it would be a nice flyer, switch app, saving it as an AD or APub document depending of the purpose.
If there's no need to interact further with the image or elements composing it, I can import it in an AD or APub document.

If you have a lot of text in a document, it's better to use the app best suited for managing text from the start: APub.

 

47 minutes ago, R C-R said:

I am not sure I understand what you think you would loose by opening a native format file in a different Affinity app than the one that created it.

When you work in this area for long, it's the same as when drawing, you use the more adequate tool for your purpose. No pencil when working on a 4×3 m canvas, but big brushes. No book or magazine created in AD or AP if you've got APub.

If your template is made to create a bunch of icons, with the already set slices, exports slices parameters with complexes paths, etc.,  why would you open it in APub?
If you've got a complexe magazine template, with a lot of pages and master pages, using specifics features like facing pages, why would you open it in AD or AP?

Perhaps you're confusing presets and templates. Presets are overall settings for a document, and that's not really a problem which app you use them with (but they are inherent to each apps, and you can't open them in another, you need to recreate them in the other apps).
Templates are, for example what I use the most, complete magazines with text (lorem ipsum or not), image placeholders, variables.
The template is use for each new issue of the magazine, inserting new texts and new images, exact variables, etc. in this new file.
Why do we use it to create a new document instead of using the last published issue? Because in the last issue we can have modified too much the pages layout, the headings, the place for images, to suit the specific of this last issue.
But when signing with a client, we work on a "maquette" (model), until it's validated. Once done, this is used as template, and the client's got a "chemin de fer" (agreed upon heading for pages, content of pages, position for adds, etc. and possible variations or headings for some pages), with a "calibrage" (calibration? max content of text by page or articles, plain page pictures or small illustrations, etc.) to respect. With this, he know from the start how many articles (and the lengh for each one) and how many pictures he needs for his magazine. The same as we knwow what he should provide for his magazine.
Knowing this, it's easy for the 2 parts to work together.

You can also use templates for adds, or flyers, if you need consistency in the design. For books also.
Templates are usefull for advanced works. You usually don't open advanced work in the wrong app.

You can have simpler templates with only one or 2 pages or artboards, like for CD or complexe form like jacket the printer need to cut precisely and fold. You can open those in any apps since they are simple, and switching or using another app won't  be a problem. Only for those a generic extension is relevant.

If you only need a blank document, using the presets is best suited.

1 hour ago, R C-R said:

You can also open any .afpub file in AP or AD & still have full access to its pages, again including master pages, & even change document properties like facing pages or the image replacement policy. (Like I said, this also works with the iPadOS versions of AD & AP.)

Really? But why would I do that unless I'm stuck on an isle with only AP and without Internet to download and install APub? I know I can do magazines in Words too, but I don't wan't to. I'm confortble using the right tool for the right task. It's usually easier and faster.

 

1 hour ago, R C-R said:

nothing in the document is lost if for whatever reason you want or need to use several of the apps to work on it.

Again, it's not about loosing anything in the document, but loosing features or easy way to do some tasks. Like being in AP and not being able write text on curves, or needing to right click and search for the operations you would do in a click or with a shortcut in AD like expand a stroke. Same problem the other way when lacking some features in AD or needing to do more convoluted actions. You can always switch app, but it's simpler if you open the file in the right app from the start.

 

 

1 hour ago, R C-R said:

I think the developers have spent a lot of time working out the considerable complications involved in creating native file formats

No problem with that, but having more file extentions doesn't mean rewriting all the code or modifying the file format. Only modifying the extension used when exporting as template for each app ("save as" would be better with 2 options, the default one set to afdesigner|afphoto|afpublisher), and processing the 3 templates extensions the same way as is processed the curent aftemplate one.

[R C-R]

1 hour ago, Wosven said:

The logical step is to switch back to the original app and export the template from there.

If I am happy with whatever I have done in APu (or whichever other app I am using at the time) & ready to save it as a template, why would I want to take the extra step of switching back to the original app just to save it as a template from that app? For that matter, I may have switched among the apps several different times during the design process for any number of reasons (to grab an asset I saved in one app but not another, to use a vector brush I saved in one but not another, maybe to save a few slices for later export, to name a few), so the whole concept of the 'original app' begins to loose its importance, particularly considering that I may well want to use that same template as a starting point for a project completely or mostly done in any of the apps.

Earlier, you mentioned something about wanting this to be as automatic & as free from human error as possible. How would expecting users to always remember to switch back to the original app serve that goal?

2 hours ago, Wosven said:

Again, it's not about loosing anything in the document, but loosing features or easy way to do some tasks.

What specifically does this have to do with creating templates? I switch among the apps when creating templates because I do want to use the tools in one app that make some task easier, just like I do when creating any other kind of document. But if I can do a series of tasks in one app without having to switch to any of the others, why wouldn't that be the easiest way to do it? There is a lot of overlap in the features so for example, if I switched to Photo to use its Liquify persona on some element & the next several things I decide to do are just as (or more) easily done in one of its personas, why not do them there in that app, & only switch to another one when the need arrises?

I am not loosing anything by doing this. In fact, I am gaining more use of the flexibility already built into the suite.

3 hours ago, Wosven said:

No problem with that, but having more file extentions doesn't mean rewriting all the code or modifying the file format.

At the least, it means adding some new magic numbers or other identifiers somewhere in the format because there are not any I can find in the usual place at the beginning of the native document format files other than the 16 characters at the beginning that are exactly the same in every native document file, .aftemplate files included. (If you don't believe me or think I have missed something, it is easy enough to do your own tests with a text editor that will show all characters.)

That in turn requires at least a minimal amount of additional code to add them to these new template filetypes & to keep track of the original app to know which one to add. It also requires additional code to handle opening them for editing or template use if someone tries to do that in a different app than the original one. Something would have to be added to the iPadOS versions as well, & it would have to be compatible with that OS's sandboxing restrictions.

So while not all of the code would have to be rewritten, some of it certainly would & we can only guess about how much work that would involve.