A_B_C

Maybe we should think a little outside the box, or rather, outside the frame, as it were. What if we thought in terms of grids and areas instead of text frames? I imagine there could be a new structural (“logical”) layer in a Publisher document for complex book typography that would define semantically tagged layout areas where the application would dynamically place (linked) text frames according to rules we define. Have a look at the following diagram.

In developing a layout template for a book, we would not start with defining primary and secondary text frames for our contents, but we would start with defining semantically tagged layout areas that come with certain rule sets (A). These areas could be of different types. We could define, for instance, shared spaces for body text and footnote text frames in a more or less traditional sense (A, solid turquoise rectangles). On a layout spread (B), at the beginning of a story, we would initially be presented with a text frame there, and the application would dynamically create body text and footnote text frames according to the contents we would paste or import into this initial frame (B, turquoise rectangle frames).
But there could also be tagged areas that are of a different type, but semantically or functionally linked to other frames, such as the solid pink areas indicated in the diagram on level (A). By defining these areas, we could tell the application
“See, we want to have our side notes placed here. Whenever there is an anchor of a certain type in our body text frame, create a text frame in the side notes area, and add the side note text which is the target of this anchor to this frame.” Or we could set a different rule. We could tell the application
“See, we want to collect all our side notes in one text frame at the bottom of the page. So when there is an anchor of a certain type in our body text frame, create a single text frame of variable height, aligned to the bottom of the pink area, and add the side note text which is the target of this anchor to this frame. In case there already is such a text frame, simply add the note text to it.” Let me emphasize that I do not think of the tagged areas in (A) – or of the entire “layer” (A), for that matter – as objects in the current sense of the word “layer.” Like a text frame or a vector shape is currently thought of as a “layer” in a document. The word “layer” has a merely structural (“logical”) meaning here. Sure, there would be a UI for drawing tagged areas of the envisioned kind, but this UI would be much like an UI for drawing a complex grid or creating a set of guidelines.
All in all, I think the current idea would very much reflect the actual way in which typographers develop the layout structure of a complex publication. There are always structural questions to answer. “What kinds of content do we have?” – “Will there be footnotes or endnotes?” – “Do we need margin notes?” – “What about images and illustrations?” – “How can we organise our spreads, depending on the contents we have to care for?” – and so on. The more technical questions, for instance, the question concerning the best layer structure for the document, will almost always come later.

I find all these ideas very interesting and highly thought provoking. @A_B_C, I must congratulate you on some highly imaginative forward thinking.
But if I can just interject with a thought: of all the different styles of 'notes', I would think that endnotes are the easiest to achieve as it entails placing a single block of 'notes' at a specific place in the document, i.e. end of chapter or end of book. This, from a personal point of view, would satisfy me and probably many other book publishers, so would it be worth Serif progressing this feature to completion prior to all the other different types?

Yes!! Part 3 is just freshly published in both English as well as in Dutch! 😊 Hope you like it! In the end there will be 6 parts in total. Collect them all ! 😉
This time a very interesting time period with a lot of technical graphics innovations, a steady foundation of 3D graphics, techniques we still often use today, some things you might be surprised by, the beginning of the home console and PC market and more! Enjoy!
English: History Interactive Computer Graphics - Part 3
Dutch: Geschiedenis Interactieve Computergraphics - Deel 3

 
@Alfred @Madame @Roger C @GarryP @Wosven @A_B_C @WatcherMagic @John Rostron @Renzatic @dutchshader @CLC @SrPx @haakoo

I do agree with you there, but that would be a case for the typical implementation where footnotes are automatically put at the bottom of the same frame. I do advocate for that basic and familiar approach no matter what other more powerful approach is adopted. A few posts up I suggested that there could be three potential options, the first two being footnotes and endnotes like we have seen them in other software. The suggestions I have made in the subsequent posts were concerning the third option, to cover different cases where the usual approaches falls short. It is an exciting idea, but I do not mean it should be done instead of the traditional approaches. In fact, I would still likely use the traditional more often if it were there.

Thank you @Old Bruce for your thoughts. I think that pinning text frames (side notes) to the main text is too fragile and is a hack as far as I am concerned. Peter's script does it because this feature doesn't exist in inDesign. I hope that Affinity will be able to come up with a solution that is more maintainable. And hopefully we the community will be able to push Affinity in the right direction.

To be honest, I am not sure whether the kind of dynamically updating notes we are discussing – footnotes, endnotes, margin notes, multi-column footnootes and so on – would work very well on the basis of currently existing page models and page elements such as pinned text frames. Rather, I would imagine that it should be possible to define functional relations between master text frames that would be associated with rules how to fill these frames with content.
The kind of typography we are talking about is usually a highly formalised one. When you decide for a certain type of notes to be added to the main text, you won’t usually change this type throughout your document. Sure, you may have different sorts of notes, for instance, margin notes as well as footnotes. You may also have different reference or numbering systems in the same document. But unless you intend to confuse the reader, you will most probably make sure to keep the chosen layout structure consistent. It’s not like you’re creating an advertising folder for your local supermarket where each spread might be different from the others.
Therefore, I believe we will need the ability to assign a more sophisticated functional structure to our spreads, beyond the way we can already define a master text frame that is intended for automatic text flow. That is to say, there must be an option not only to determine the place where the main text should reside, but also areas where accompanying notes should live.

If we take the example from Peter Kahrel’s script page linked above and apply the present suggestion to this example, we would be able to define the linked blue text frames containing the main story and, in addition, the red margin note frames, probably linked, such that a margin note could extend to the next page, if desired. The red frames would be logically attached to the first frame of the main story pipeline, and the application would take care of the proper placement of the margin notes within the red frames. There could be, for instance, the following alignment options:
Align margin notes with respective text anchor (Kahrel’s example) Collect margin notes at the bottom of the page Collect margin notes at the top of the page

The ideas from @ABC are interesting. But if you need margin notes and footnotes on the same page, how would it work ?
I'm a bit skeptical about this need to impose a style of notes from the start.
In any case, I think it should have a panel listing all of the notes in the document ... much like the Index panel. This would provide an overview of all the notes. For example :
Page 12 :
(1) : Description of note 1 (2) : Description of note 2 (3) : Description of note 3 Page 15 :
(1) : Description of note 1 Page 23 :
(1) : Description of note 1 (2) : Description of note 2 (3) : Description of note 3 By clicking on the page number or on a particular note, the user would be redirected to the page / note in question.

I'm sure the fact that footnotes are hotly desired in the community is now abundantly clear to Serif, so my thinking is that further "we need footnotes" comments won't make much difference in the timing of when we get them. On the other hand, as we talk about implementations, I do hope that our thinking through this together will be of use to Serif when it comes time to implement a particular approach.
And there have been some good ideas mentioned over the weekend. First…
I think that is a good observation—not that I know anything about the feeling of Old Bruce's brain, but that this is no small problem. It is easy to say that footnotes should be able to do X, and it should be better than how InDesign does it, etc. It is a good deal harder to conceive of a suitable UX for bringing this about, so I appreciate Old Bruce's comment.
Before going on, I feel like the term "footnote" is not quite the thing, because we are talking also about endnotes, sidenotes, and who knows what. I propose the term "text notes." Perhaps the term will catch on if it has merit, but if not, at least you'll know what I mean throughout this post.
Before we get too complicated, I do think the basic footnotes at the bottom of the frame and endnotes at the end of the story should be available options, and maybe that is where Serif should start in the first iteration. It's the simple approach for those who are less familiar with advanced features of the software, and, frankly, for all of us in those times when that is exactly what we need—a rather frequent scenario, I would think. But when we need more power, I think @A_B_C's suggestion is the right direction for accomplishing this powerful "text notes" system, (and I would 💟  his post more than once if it were possible):
A separate frame that is tagged with a particular text notes set would be great, and it opens the possibility of multiple groups of text notes in a single story. Imagine, for example, if you could define different sets of text notes (like you can define different Tables of Contents). You could have traditional footnotes at the bottom of the page. Then also endnotes for, say, bibliography references, another text notes set that would be side notes, that would go in its own frame as defined by the master page. The simplicity is that if I name a text notes set as "sidenotes A," then in my master page I create a text frame and somehow tag it as containing the notes of "sidenotes A," then Affinity really only needs to treat it as a separate frame with its own contents. All it has to do is fill the contents as it processes the main story, but otherwise, it is just another text frame that behaves just like a regular text frame.
Maybe; but I think this would have limitations as compared to a separate frame semantically tagged for the purpose. For example, what if you wanted the notes to be somewhere outside of the frame, maybe on the facing page of the same spread? If we had the subframe idea, you would need to make one really large frame to expand the whole area, and then it might be hard to achieve the position of the text notes portion relative the story portion, and the possibly large gap between. A separate frame means that the existing paradigm of how frames work would still apply. Text wrap, for example. Also the ability to override the size of the frame as defined in the master page for particular cases where it is needed.

To be honest, I am not sure whether the kind of dynamically updating notes we are discussing – footnotes, endnotes, margin notes, multi-column footnootes and so on – would work very well on the basis of currently existing page models and page elements such as pinned text frames. Rather, I would imagine that it should be possible to define functional relations between master text frames that would be associated with rules how to fill these frames with content.
The kind of typography we are talking about is usually a highly formalised one. When you decide for a certain type of notes to be added to the main text, you won’t usually change this type throughout your document. Sure, you may have different sorts of notes, for instance, margin notes as well as footnotes. You may also have different reference or numbering systems in the same document. But unless you intend to confuse the reader, you will most probably make sure to keep the chosen layout structure consistent. It’s not like you’re creating an advertising folder for your local supermarket where each spread might be different from the others.
Therefore, I believe we will need the ability to assign a more sophisticated functional structure to our spreads, beyond the way we can already define a master text frame that is intended for automatic text flow. That is to say, there must be an option not only to determine the place where the main text should reside, but also areas where accompanying notes should live.

If we take the example from Peter Kahrel’s script page linked above and apply the present suggestion to this example, we would be able to define the linked blue text frames containing the main story and, in addition, the red margin note frames, probably linked, such that a margin note could extend to the next page, if desired. The red frames would be logically attached to the first frame of the main story pipeline, and the application would take care of the proper placement of the margin notes within the red frames. There could be, for instance, the following alignment options:
Align margin notes with respective text anchor (Kahrel’s example) Collect margin notes at the bottom of the page Collect margin notes at the top of the page

Sorry, I've found them after all!
It is under View>Show text rulers

Indeed, it’s pretty difficult. In a way, I would imagine a possible solution could work along the following lines. What if we toyed a little with the concept of a subframe of a text frame? A subframe would be a text frame inside a text frame, something like a column with its own text flow options, separated from the text flow of the main part of the text frame, designed for receiving secondary contents like notes. Please have a look at the following sketch:

Suppose we would like to have margin notes besides our main text. Then there would be a new section on the Text Frame Panel called Subframes. There we could select a layout type, in our case, Margin Notes. But there could also be dedicated footnote layouts, even a Customize … option that would allow us to place our subframes inside your text frames at will. Depending on the selection made in the layout part of the section, we would get different settings or options. In our case, for instance,
width (height) and gutter settings for the subframes,  settings concerning the dynamic resizing behavior of the subframes relative to the enclosing text frames (important for footnotes proper: how to balance the main content and the subframe content, cross-spread text flow options for footnotes etc.), the option to select a type of content for the subframe (in our case, margin notes attached to anchors in the main text with certain numbering options), content alignment options for the subframes, etc. Following this idea, we would overcome the problem with dynamic resizing that dawned on me shortly after I had made my first suggestion. Maybe it would be fruitful to think forward along these lines. 😀

OK
 

Hi MichaelMeeuwissen,
Try to resize the image of the face used in your first post in the previous version of Photo that you think doesn't pixelate. You will see the results are the same and the face becomes pixelated there too. The video you posted above resizing the balloons is a little misleading because the image characteristics are quite different (detailed face/clean ballon) as well as the amount of resizing you performed.

Hey MichaelMeeuwissen,
Which previous version? There was a bug in the earlier versions of 1.7 where the Export Persona would be incorrectly displaying objects as vector objects.
Designer and Publisher will only pixelate the image layer once it has been resized and rasterised as it will initially use a vector view, but Photo will always be displaying objects in a raster format, regardless if it is an image layer or shape etc.

Hi there!
Well, more than a legend in a good sense, the first try of Microsoft to bring Internet Explorer to the "present" back then. I must say, I always liked this kind of Icons, so, I had a little time to play a little and try to reproduce Internet Explorer 7's Symbol:

May I will do Edge next... If anyone is interested, I attached the source file.
Hope you all are doing well.
Best regards!
Internet Explorer 7.afdesign

Indeed, it’s pretty difficult. In a way, I would imagine a possible solution could work along the following lines. What if we toyed a little with the concept of a subframe of a text frame? A subframe would be a text frame inside a text frame, something like a column with its own text flow options, separated from the text flow of the main part of the text frame, designed for receiving secondary contents like notes. Please have a look at the following sketch:

Suppose we would like to have margin notes besides our main text. Then there would be a new section on the Text Frame Panel called Subframes. There we could select a layout type, in our case, Margin Notes. But there could also be dedicated footnote layouts, even a Customize … option that would allow us to place our subframes inside your text frames at will. Depending on the selection made in the layout part of the section, we would get different settings or options. In our case, for instance,
width (height) and gutter settings for the subframes,  settings concerning the dynamic resizing behavior of the subframes relative to the enclosing text frames (important for footnotes proper: how to balance the main content and the subframe content, cross-spread text flow options for footnotes etc.), the option to select a type of content for the subframe (in our case, margin notes attached to anchors in the main text with certain numbering options), content alignment options for the subframes, etc. Following this idea, we would overcome the problem with dynamic resizing that dawned on me shortly after I had made my first suggestion. Maybe it would be fruitful to think forward along these lines. 😀

Of course, the system described above only works when the size and the position of the text frames that contain the notes can be made independent from the size of the text frames that contain the main text. So it will only work for margin notes as in the example above. Otherwise we would need a dynamic constraint-based system like in Designer that would determine the size of text frames dependent on the size of other text frames. Hmm. 🙁
(I’ve deleted the last paragraph of my previous post, as it was basically wrong without further qualifications.)

Made this with affinity designer . No raster layers , only vectors

Visit any university library and you'll find that endnotes replaced footnotes long ago, perhaps in the 1950s. In the era before computers, endnotes were far easier to typeset. In todays world, their appearance at the bottom of a page is seen as clutter by most readers.
While this might be true up to a certain point for academic publications in the English-speaking world (and while there is a certain international convergence in recent years), there are also cultural differences. German academic publications are still heavily using footnotes for reference purposes as well as for comments and clarifications. And while footnotes might be perceived as clutter from a typographic point of view (it can be incredibly difficult to typeset certain sorts of academic texts in a visually pleasing way), they are much more practical for readers. Personally, I don’t like reading a book from two ends.

We are pleased to announce Affinity Designer, Affinity Photo and Affinity Publisher are now all updated to version 1.8.3 (for all new and existing customers).
Here are links to the release notes
Affinity Designer 1.8.3 for Windows            ( Microsoft Store and Affinity Store ) Affinity Designer 1.8.3 for macOS               ( Mac App Store and Affinity Store ) Affinity Designer 1.8.3 for iOS                      ( Apple iPad Store )
  Affinity Photo 1.8.3 for Windows                ( Microsoft Store and Affinity Store ) Affinity Photo 1.8.3 for macOS                   ( Mac App Store and Affinity Store ) Affinity Photo 1.8.3 for iOS                          ( Apple iPad Store )
   Affinity Publisher 1.8.3 for Windows         ( Microsoft Store and Affinity Store ) Affinity Publisher 1.8.3 for macOS            ( Mac App Store and Affinity Store ) Please follow this thread here to get notified when any new releases are made

Hi bboysupaman,
please have a look at my video linked below (Clipping_vs_Masking.mov).
In (A.) the pink rectangle (or rather square) gets clipped to the boundaries (path) of the blue triangle, and this is done by making the rectangle a child of the triangle in the layers list. This is called "layer clipping".
In (B.) the rectangle acts as a mask applied to the triangle, and this is done by dragging the thumbnail of the rectangle directly onto the thumbnail of the triangle in the layers list. (Note the differences between the blue highlight bars appearing while the list entries are dragged to their respective positions.) Now it is not the rectangle that gets clipped to the boundaries of the triangle, but the rectangle clips (or cuts) parts of the triangle. This is called "creating a vector mask".
Hope you get the difference …
Kind regards, Alex 
 

Clipping_vs_Masking.mov  

 

Not in designer, but if you also have Affinity Photo
1. Create some Artistic text
2. Filters > Distort > Equations
3. Enter formula shown below
4. Adjust the Slider A to vary the effect
This is the formula
y-(120*a)*sin(380*x/w)
 

These forums work quite well, but having a single place where bugs could be tracked would clearly improve the experience. We have looked into ones that plug into (work with) these forums but as yet have not found one that does what we want. We do not want an independent bug tracking system that requires another account to be created, so one that uses this forums login is a prerequisite. Also this is something that has to work for our whole development department, which does not add to our workload.

Status: Release candidate
Purpose: Features, Improvements, Fixes
Requirements: Purchased Affinity Designer for iPad From App Store
App Store: Not submitted
Download link: Download
 
Hello,
We are pleased to announce the immediate availability of the first release candidate of Affinity Designer 1.8.3 for iPad.
If this is your first time using a customer beta of an Affinity app, it’s worth noting that the beta will install as a separate app - alongside your store version. They will not interfere with each other at all and you can continue to use the store version for critical work without worry.
This beta is an incremental update to the 1.8.2 version recently released to all customers. We recommend that you use this beta in preference to the store version if you are affected by any of the issues listed below.
We are moving to release candidate stage early for 1.8.3, due to the discovery of a bug which prevents auto save from working in most circumstances. This bug can cause significant loss of work for users and is classed as extremely high priority. Once 1.8.3 is released, we will be back with 1.8.4 betas relatively quickly.
Please note that the download link provided is a Public TestFlight link and will work for anyone as long as they have the App Store version of Designer installed. There is no longer any need to contact us to register for the Beta directly.
Thanks,
Matt
 
Changes This Version
- Fonts are now correctly ordered in the font chooser.
- Colinear curve sections are now correctly dealt with during boolean operations.
- Fix for geometry operations always being enabled, even when inappropriate.
- Improved expand stroke for curves with rapid pressure variation towards their start/end.
 
Changes Since 1.8.2
- Autosave fixes.
- Fixed rendering issue with small radius filter effects.
- Significant stability improvements for 2GB, 3GB iPads.
- Performance improvements for 4GB+ iPads.
- PDF export fixes.
- New document from clipboard improvements.
- Boolean operation improvements (excluding Divide operation).
- Assorted small crash fixes.
- Numerous small performance improvements.