eluengo

I think is's not really a problem of the 3 AFF apps, but since the actualization to the last Sonoma version (14.3) in my M1 Mac, the ultraslow first launch that we used to have before M1 has returned: frequently more than 30 seconds after dock-click lasts to appear the AFF window. Its probably an OS problem, but it's annoying. It happens only on the first launch after computer (re)start, next launches are near instantaneous, as we used to.

Sorry, NO, Walt, in standard interface guidelines ellipsis after a menuitem is *always* leading to an ampliation of information the app needs to execute the adequate command. In MacOS this has been so since 1984. There is no exception neither option. 
Otherwise, the absence of ellipsis should (originally) lead to the inmediate execution of the command. This second rule has been broken so frequently that today no one is surprised if after such a no-ellipsis-menuitem comes a info-extension dialog. Is another error, but so frequent that isn’t really of interest. But both are errors.
A different thing is that a such minimal question needs to be corrected or is really not necessary, I think it’s not.
BUT this interface discipline is law (like other rules), and good practice, in the Mac universe (this is not necessarily so in other OSs, could every interface method or interface manager have its own rules and directives).
A good interface design and interface rules are the best way to quick and errorless work.
Regards
Emilio

Sorry, NO, Walt, in standard interface guidelines ellipsis after a menuitem is *always* leading to an ampliation of information the app needs to execute the adequate command. In MacOS this has been so since 1984. There is no exception neither option. 
Otherwise, the absence of ellipsis should (originally) lead to the inmediate execution of the command. This second rule has been broken so frequently that today no one is surprised if after such a no-ellipsis-menuitem comes a info-extension dialog. Is another error, but so frequent that isn’t really of interest. But both are errors.
A different thing is that a such minimal question needs to be corrected or is really not necessary, I think it’s not.
BUT this interface discipline is law (like other rules), and good practice, in the Mac universe (this is not necessarily so in other OSs, could every interface method or interface manager have its own rules and directives).
A good interface design and interface rules are the best way to quick and errorless work.
Regards
Emilio

Thanx
Both advices were correct.
I need to remember when opening older dox

Light interface… less rethinked
ergonomically is better a light than a dark interface.... but the dark interfaces are trendy 🤷‍♂️

Is an interface concept error, more than a bug (and probably related to how MS Windows does)... is inconsistent that a window that has a group of OK-Cancel buttons has also any of the window buttons/semaphore (red, yellow or green) active or ever existent.
Correct would be, either with semaphore buttons (eventually + confirmation of secureness of action) or without semaphore and OK-Cancel buttons group, bottom-right (also eventually + confirmation of secureness of action). And Cmd-W should only affect the topmost window and only if the semaphore exists or is active.
Comparing with old user interface rules, modern Mac rules/habits are so flexible that sometimes designers get confused (if not mad) and permit some inconsistencies. Also sometimes designers are forced to this attitude because of compatibility necessary in multiplatform app designs.
It's only an opinion
🖖

Designer and Publisher (apparently not Photo) launches slowly since MacOS Big Sur 11.1 (i.e. 45 dock icon bumps) in its first launch after Mac reset or after a while closed (versus 4 icon bumps when recently launched).
Why?, is it normal?, is OS guilty or the app?, Apple Silicon Macs will solve it?
Emilio

Designer and Publisher (apparently not Photo) launches slowly since MacOS Big Sur 11.1 (i.e. 45 dock icon bumps) in its first launch after Mac reset or after a while closed (versus 4 icon bumps when recently launched).
Why?, is it normal?, is OS guilty or the app?, Apple Silicon Macs will solve it?
Emilio

mmmm, i’ll try to recreate the circumstances, but as I discovered the “solution” (putting TOC in an independent text frame) I began tu put more and more text of a long manual, for which I have to complete text and recreate all the graphics (all that in my free time, as I’m physician). I’ll try and send U the file. Thanx !!

I customized which panels from View>Studio menu I want to have in my workspace (as u see in the screen capture)
Every panel opens with one clic and closes with double clic.
And all is tidy and ordered.
But I also think it would be interesting that those panels contract to single icons, like those in the left tools panel.... (yes, I know, it's not the standard user interface for Affinity products {and too similar to Adobe products}, but is only an idea....)

I customized which panels from View>Studio menu I want to have in my workspace (as u see in the screen capture)
Every panel opens with one clic and closes with double clic.
And all is tidy and ordered.
But I also think it would be interesting that those panels contract to single icons, like those in the left tools panel.... (yes, I know, it's not the standard user interface for Affinity products {and too similar to Adobe products}, but is only an idea....)

Hi
Some problems in spanish localization
(Otherwise, a good translation into spanish!!)
(1)  Texts too long..." Alcance: Documento"->Doc. || "Buscar en: Todos marcos de texto" ->Todos marcos txt ||  The second half of the conmuting button is not to be seen, but "Text Flow" in english version can be "Flujo de txt"  ||  texts in next two checkboxes is too long and too compact and small... difficult to read: probably simply changing "tabla de contenido" to "TabCont" or "TabDeCont" (ie. "Detener en siguiente TabCont")
(2)  Propiedades button.... either button a bit longer or abbreviate Propiedades... with "Propiedades" (without "..."), or with  "Props..."
(3)  Too long and difficult to understand "Retraso de la descripción de herramientas", can be abbreviated with "Retraso de ayuda herramientas"
(4)  Instead of "Ampliar" in this menu, better could be "Expandir"
(5)  Instead of "Cambiar interfaz de usuario" (difficult to understand what the command does, better could be "Ver/Ocultar interfase" or "Conmutar interfase"
(6)  In this pop-up menu change "Valor Predet." with "Predeterminado", and also could be a polite image that all language options are capitalized, and not only both Englishes (GB and American) and German.... "Español, Italiano, Português, Français, Русский"
(I apologize for the big screenshots.... has to do with retina screen capture, surely)
Emilio
(1)
(2)
(3)
(4)
(5)
(6)
 

form fields and interactive pdf export would be nice

I would love this even if we only had Selection as a choice.

Styles in afpub isn't really an easy thing.
As doesn't in ID neither in Word or Pages.
But in afpub the interface doesn't help so much.
My personal solution...
-- deleting all styles EXCEPT both "no-style" styles, the paragraph one and the character one (and I send you with this text an afpub file with THOSE styles' characteristics). AND making this the default Styles in afpub (selecting it in the little menu appearing from the upper right corner of theText-Styles panel).
-- for every proyect.... creating (or not) a base page with the styles I will use (or not).
-- understanding that every Paragraph-Style has a Character-Style implicitly, and that Character-Styles mean only modifications to this base Implicit-Character-Style (so... using any character styles to different paragraph styles will make the general style structure of the document confusing, cumbersome and sometimes with an erratic behaviour).
I don't know if this can help you, but it was for me.
Emilio
A4v.estilo nulo[afpub].afpub

Hi all. What do you think about have a "Print Persona" to replace the print dialog box? With a preview in large size (not the small preview of the dialog box).
In this "persona" you could perform all the pre-printing tasks that are currently performed in the dialog but in a more comfortable way.
Even in the future, more advanced imposition options and other pre-printing tasks could be added to this "persona".
I think that printing is an important part of the workflow and deserves to have a "persona" dedicated to it.

Me agrada mucho el software pediria que introduzcan una funcionalidad para Matematicos, ingenieros donde se pueda introducir formulas matemáticas, lo cual quita mucho espacio de difusión dentro de la ciencias 

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.

Hi!
Somebody can tell me about possibility to implement multiple footnote/endnote threads in upcoming Affinity Publisher?

Can not convert text (with tabs) to a table?

Hello,
1/ What is the quickest way to restore an (embedded) image to its native aspect ratio ? (I don't have any external copy of this picture and after a lot of changes, I can't remember the original dimensions...).
2/ What is the quickest way to "extract" an image from my Publisher document to get it on the desktop ?
Merci !

a little bug
when stretching vertically a text box (or a group or collection of elements with a text box included), if handle (and box) exceeds page limits, suddenly the box disappears. When releasing the mouse  button it reappears where it shoud be.... (video)
pantallazo 2018-10-15 a las 19.31.38.mov

Yes, those are all valid questions. And then there are users like me, who would be [more] actively participating in the Beta if they only had the time. It's extremely frustrating, as an old-timer beta tester, to not even be able to really put the apps through their paces, but such is life (and I am certainly representative of the people who will buy this thing – and I will, anyway, regardless of how incomplete it is; I am treating Affinity a bit like if it was a Kickstarter project – because a) I already bought the other two, b) I've been using ID professionally for almost 10 years now and c) I don't intend on leaving the DTP market any time soon).
As for feature dependencies… Sure, we don't know exactly which are dependent on which, but we can take some informed guesses. Seeing how Affinity Publisher is based on the same codebase as Affinity Designer, the internal support for variable page sizes (which should be just a different, more specialized implementation of artboards, after all) must be there already in some form, as should be the option of having more than two pages per spread.
It should be just a matter of exposing it via the UI, adding a spine indicator and getting the pages to snap nicely to one another (and that's yet another area in which Serif could one-up Adobe; I've always hated how when you change some page's size, the adjacent ones don't snap neatly to it automatically, forcing you to break your spreads apart and rejoin them…), and while I can appreciate that it might take a while to implement, it should be an absolute priority for a self-proclaimed “professional” DTP app. Otherwise, when it comes specifically to page management, it behaves just like a glorified text editor, am I right?
And the same goes for in-line, anchored objects… No self-respecting designer would start more complex projects in Publisher if that meant they would take even more work to do than even editing a Word document. That would defeat the whole purpose of using a dedicated DTP app, and would make the amateurs/prosumers default to Word/Pages and the professionals default to InDesign/Quark. That's why this thread is so important, and why I'm guessing at least this feature in particular will arrive in time of the 1.7.0 GM release.

Hi everyone !
such a lot of work on this excellent beta!
so, my question is about footnotes and endnotes, a feature that is fully useful for several publications I publish. Is a roadmap for them in a next time?
 
thanks!

could be interesting to have either a button or a simple keyboard command to hide ALL... margins, squares containing text or graphics, grid, etc... so in a moment is possible to see EXACTLY how the page will be printed without the interference of all those unprintable elements.