Search the Community

A package file contains a folder for fonts. The file should use those fonts, and not the ones installed on the system. This to ensure there's no missing fonts, and since it's possible the user didn't create the package. It would avoid problems in case: the user already have the fonts installed, but with different versions (and he shouldn't modify the fonts used in a package if everything work right... or it's taking chances to need to do a lot of adjustements in the text). the user/printer need to make few corrections before exporting to PDF and printing. It would smooth the work flow if the package weren't some sort of dead files unable to use those fonts or be simply saved after a modification.

Ok, so I've downloaded and installed files for Indonesian, however I cannot get the language to function. I can select it in the paragraph styles or character palettes but spell checking doesn't occur (all words become squiggly underlined) for spelling and hyphenation, so clearly something is wrong (I'm using Publisher V2 but don't think this has altered anything). I've positioned the hyphenation dictionary in both suggested locations (within Publisher Package > Dictionaries and/or User Library > Spelling) and placed the .aff and .dic files in "Spelling" too. Can anyone offer any help? (language is supplied so I'm happy its OK and specify as "None" to clear irritating errors, but would be happier if the language would function as the built in examples do and that Publisher could offer hyphenation where necessary automatically. Frustrated!

Why would a company choose NOT to include templates in its DTP package? We could speculate at length as to what the absence of templates indicates about such things as company abilities company staffing levels company attitude toward its customer base company attitude toward widening its customer base company understanding of its customers' needs, purposes, and desires company attitude toward attracting new customers company understanding of software usability company understanding of world market company goals and directions I myself use DTP only a few times each year to make greeting cards, business cards, and sometimes a newsletter. I bought APub three years ago, but I always return to Microsoft Publisher because its templates launch me easily into whatever project I'm working on. I recommend Microsoft Publisher to my relatives and friends because the templates get one started. Templates have served that purpose in every word processing and DTP package I've used over the past 35 years. My young grandchildren also use Microsoft Publisher for greeting cards and school projects. Affinity Publisher obviously is aimed at a market that does not include me and my granddaughters but one that does include those who argue vehemently against including templates. I do not understand that vehemence. If one does not need templates, why oppose them for someone who would find them useful?

I had an epic essay written describing my workflow as a package designer and the difficulties in using this layer system and it's lack of global layers. While writing it, I reevaluated my whole workflow structure and template system, digging in deep to all aspects of the Master Pages and Layers to see if I could come up with a way to make it all work. It was an interesting and informative journey, the tale of which is way to boring for anyone here to slog through. My primary findings boil down to what many others have said before: I need a level of layer-like containers that are independent from any Page or Master Page with the ability to show/hide those layers of content across the entire document with a single toggle. For those still interested in reading, my document structure as a package designer includes: top level dynamic and static artwork layers that may overlap the packaging "window" layer which in turn overlaps dynamic and static artwork layers in the background. Static art is branding and info that appears on all packages. Dynamic art are images, colors, etc. that change based on the particular "flavor" of each package. Additionally I have a topmost layer with printer die lines, and the window layer is actually 2 layers: one with the window containing a spot color for export to the printer and one with the window containing the product image for exporting to make a 3D render of the "filled" package. In InDesign, I have 5-7 global layers, and 2 master pages Front and Back. I can, with a single click, toggle the die lines to check my artwork fits properly. I can, with a single click, toggle the 2 window variants depending on my export intent. In APub, to achieve a similar set up, I came up with 2 approaches. 1. Create 5-7 layers in each of the Front and Back master pages with ALL design elements present in these masters. When working on the dynamic aspects of the design, any master text is easy enough to edit, but all other objects and shapes, I have to constantly "edit detached" to manipulate things. Very tedious. 2. The reverse approach to keep the dynamic art independent from the master pages making them easier to edit quickly (no "edit detached"), was to created 10-14 Master Pages (5-7 for both Front and Back), each with a single layer of content. That means each page needs 5-7 Masters applied and correctly sorted in each page's layers panel. Also tedious. Neither of these approaches are great, #1 is a pain to work with during the design process, but once the design finalized, it's not so hard to add a new flavor or make a minor edit. #2 is much preferred during the design process as elements are still moving around and I may be jumping across pages frequently. But takes a great deal of setup time at the start and there are so many layers! So this ended up being a bit of an essay too, huh? I haven't settled on an approach yet, but as others have said, the debate might be moot since we've been told "global layers" are coming.

Hi AlphaZentauri, Welcome to the forums I'm having a lot of trouble replicating this behaviour here at my end. If you try this with a new test project using just one of your images does the same issue occur? If it does would you mind going to File > Save As package and then send me the resulting package file so I can try replicating this issue again? Thanks C

I uploaded two .zip files, one with 3 .afpubs (1 package, 2 broken) and one with several related error messages which varied in contents with different trials to re-open the .afpubs. The most oddity is that those errors happen occasionally only + mainly don't occur during work but appear to get triggered only either by "Save" (while neither .afpub path or name were changed) or when accessing APub after a working break (incl. mac sleep) with the .afpubs permanently opened. In did not fix all missing image links. It would need too much time to identify those images I had moved + renamed after placing and exporting them as wanted. Since the issues with my two daily afpubs happen occasionally only I assume it is not the missing links which trigger the errors. Same for a few missing fonts. Also I noticed when fixing missing items that often the "Relink" option did not work though file names were identically. On the last page of the .afpackage are some samples which I copied manually into the packed folder. They should not be missing at all but rather be reported as "modified" because they got re-saved only, not renamed. (After placing them I had moved + resaved them. It appears that this combination of move + resave prevents APub / Resource Manager to recognize them even if I point APub to the correct path. I don't need any .afpub to get fixed but I am interested … … what is causing these occasional issues in my two daily .afpubs with only locally save data? … how can I prevent the issues? … is there possibly any system report saved on disk which may help to detect the culprit?

If you could package up the file that works and its resources, that would be great. Feel free to also upload the corrupted files - might be useful to our QA team. https://www.dropbox.com/request/2PCfg2wbwXnOSX178KWu Thanks again.

@Leigh, which one do you want? Aside the healthy current file version of "twitter.afpub" I still have two broken versions of it (one of the two .afpubs mentioned in the screenshots above which refused to open): Since I usually add content only the two broken and larger .afpubs seem to contain data garbage which probably was removed in the current version by a Save As. Since the two broken files don't open any more I could not create a package of them but can send them as they are (as .ZIP?). Instead or additionally I could send the current, healthy version which contains the same images. (Before packing I'd need to fix some missing image links that I either just moved or, unfortunately, occasionally have renamed after their use in .afpub was done.) – So which of that 3 do you want? However, for an upload I'd prefer your dropbox. According to the summary I guess the packed size of "twitter.afpub" would be a few hundred MB. Also, I think I could find the other mentioned ("v1105 .afpub") in a backup. Let me know if it would be useful, too. (I remember I had tried one then and it didn't open either, so I assume it was a backup of the same .afpub version which didn't open some days later.)

@thomaso Me again, sorry. Is it possible to send us one of the documents you were using? Might make it easier for us to narrow down the issue. If it is, please send it as a package and if you need a Dropbox link to upload it to, please let me know.

Because - for instance - instruction manuals often has to include animations or videos showing approach, placement and tools in a repair/mounting process. In other cases, it’s a html based “widget” controlled by the user, enabling the user to control views on an detail or construct in ways meaningfull to the user in the moment in the actual environment and space available in restricted spaces locally. Paper manuals are still produced today. Seldom used for anything but emergency backups. PDF format manuals or instructions, check lists etc. are widely used, but not always sufficient. If internet can be guaranteed to be available in a sufficiently high speed (!), a link within a PDF document will often do, but try using that from an iPad with mobile connectibility, in central, old parts of Rome (where even less than megabit speeds are often the only thing available, unless you carry a few hundred meters of Ethernet cable to a reliable Cabled connection - parts of that vanishing, before ends are connected, if you do not use “security heavies” to guard the cable run). Large parts of the world - even large parts of Europe - allow only periodical and “symbolic” mobile phone internet connection speeds. In many situations, you actually need to carry “the internet parts” on you (video, audio elements - e.g. playing the sound of to low or too high tension to aid a technician - or “operator controlled explanatory elements” - typically a html based widget). You can of course use “external files”, but now you run into a versioning problem, that worst case can cause loss of life, if files end up in “unintended mixes” or even files not present on a current device recently gone into use. One ePub3 file has the same benefits as one PDF file. The PDF file is one document, with a collection of elements within. Easily version controlled as a whole (no risk, that one image is showing a year old version by end user accident). The same is the case of an ePub file (whether fixed format or not). All elements are “packed” into one, single file, easily allowing reliable versioning, including fonts and whatnot. If you have an unencrypted/protected ePub3 file called “x.epub” and rename it to “x.zip”, you can unpack the content (as you have probably done a few times, if you work with epubs), and apart from a few, central definition and control files, you’re looking at mostly near standard html content, that could be used as an ordinary “website” element (and often is, during widget development). It is actually easy to add an “active element” to a fixed format ePub (in most cases, it looks decidedly similar to a html link in a PDF file A popular description is “to place the active element” within a given frame, similar to the “startup image size”. All the elements could be regarded as one, discrete package, with predefined options for display and control. In effect, it is a “local web presentation object” requiring no connection beyond the device, but as easily integrated into a specific, physically selected “displayframe” on a screen page. The manual, instruction or check list approach is simplified enourmously by using fixed format ePub3 “Books” (using the term book, is like using the term pdf to describe the freedoms of the internet). In most cases, the web widgets are actually constructed in tools, that may target output as a html-page for inclusion into a standard online webpage, a html-widget (with the interface required to be embedded as an ePub element) or simply to a video or audio rendering, if user interaction is not required. In short - seen from the outside - you could view fixed format ePub3 documents as PDF documents with options for embedded sound, video, animation and optional user interaction, if required (“if required” being the operational phrase). Initially Adobe had a simple, embedded flash swf script approach added to PDF’s in mind, but it never cought on (it was exciting news, when I was an Adobe Postscript device driver developer late in the last millennium). Maybe it is even possible to some extend today (haven’t checked within the last ten years), but you’d run into heavy play problems (our modern world use mostly anything but strictly Adobe endorsed tools for presentation html - and the derivative ePub3 - have completely replaced that option in real life. Regards

Hi, Realmac Software, another smart independent British software company, has just announced RapidWeaver Elements, the next step in their easy web site development software. RapidWeaver is a software for Mac allowing easy creation of simple web sites without coding. It also allows limited coding, for quick customization. It also includes extension plugins. Among these plugins is Stacks, on which frameworks like Foundry or Fusion can be installed to create sophisticate modernly-designed web sites. As a result, RapidWeaver + Stacks + Foundry/Fusion can become a very powerful web site creator. RapidWeaver Elements should further develop the concept of building by blocks. Drag & drop CSS elements and scripts, and build your web site from pre-made pieces. I wonder if a collaboration between Serif and Realmac can be imagined, to make Publisher and RapidWeaver integrated in making a single-source, multi-output package allowing for creation of web sites, web help/tutorials, magazines, ebooks, starting from a common source and with a minimal amount of adaptation. Serif is multi-platform, while Realmac is Mac-only. Maybe that this type of integration can be offered, for once, to a single platform. A bit like iPad support being offered, without support for Android. Paolo

A really useful feature that would be a boon in a desktop publishing app it the ability to link document files from word processing applications to text frames in the publishing app. This may be a difficult thing to implement due to the many formats out there but certain word processing applications could be supported, as could text file editors. Also supporting RTF and TXT formats would be quite helpful. The Open Document format would be one to support, also Microsoft Word, Google Docs, Corel WordPerfect. Then we could edit the text in the word processing package of our choice and save it. When we load Affinty Publisher our document could then go about linking and loading each of the files from the save text files. A sort of text version of the way images can be linked. It would be an interesting feature to implement which could increase the DTP packages versatility no-end. Maybe after adding a story editor into Publisher we could link the files there aa well.

I am perfectly aware that Publisher it is a Beta Version. I am making the point that a Beta Version should be as close to the finished product as possible and my contention is that there are too many fundamental issues (not even bugs) that should have been ironed out earlier. In other words even as a Beta package it was released too early in the design cycle. Unfortunately the costs involved in fixing and adding things late in the development of a software package can be quite costly and also have unforeseen consequences on other parts of the software. An example of this was adding arrow heads to terminate straight lines (easy in most packages). When they were subsequently added to Designer I discovered that if you did not reselect 'no ends' when finished with the straight lines and arrowheads that arrow heads were added to any shape: square, triangle, circle etc. Now it's easy to go back and deselect arrowheads but you should not have to do this . If you select a triangle shape it should be obvious that the arrowhead feature is not required. Small thing, but so irritating in a brand new design package. With regards to the comment that familiarity with Publisher is the issue, I understand that this always is a factor. I am very familiar with many software applications in relation to Design etc. As Head of Broadcast Engineering in the National TV Station I made it my business to examine new equipment and software in a professional and non-biased way as possible. The ultimate Design package in the early years was Quantel Paintbox and I taught all the Design staff the intricacies of that system. I did likewise for our production designers and editors with many different systems. So I am very used to testing new software and weighting it so that old habits do not impinge on opening one's mind to new and better software. I built computer hardware and software dating back to the first MicroComputers in RTE's Design Lab. so I am very familiar with the design cycle of software systems. I hope I have clarified things a little more. I have no hesitation in saying that I have always had the utmost regard and admiration for Serif Products. As you say fde101 the Affinity products are completely new programs with a different design and working philosophy. I am all too conscious of that, but I am, sadly, not as impressed with these more recent products even though they are very reasonably priced for what they deliver. Regards

To add a little to what fdelaneau said, beta software can also sometimes be in a larger package than then eventual commercial release because the developers haven't done any 'housekeeping' on it yet. (For example, old versions of stuff can be left hanging around just in case they're needed.) The last Designer beta package I have is around 360MB while the package for 1.6.5.123 was around 245MB so I imagine the commercial Publisher package could be similarly smaller, perhaps. The last download for the drivers of one of my graphics cards was over 560MB, so 366MB for an application with the functionality of Publisher doesn't sound too bad to me, in this day and age. At least we don't have to install it from floppy disks; that would take quite a bit longer than 26 minutes.

TL;DR For maximum flexibility, it’s common for the licensing info to be included in a separate file in the distribution package.

It might also be useful to be able to exclude restricted fonts individually (including some, omitting some) if you know that you have the rights for some of the fonts. And along that line, it would be useful if the dialog would display the font license information, which many fonts contain, to help you make the right decision based on the use that will be made of the document package.

The concept of a 'standard tool' is one which has pervaded this thread from the beginning, if not perhaps so clearly expressed as such. Some of us have called it 'the basics', but however we express it, footnotes have always been a standard part of a DTP package. It's one of those features that are taken for granted. For months after I had bought Ap, I blamed myself for not being able to find the footnotes module: it simply could not, could not - not be there! Like @Granddaddy, I have been writing long documents for decades, starting on IBM360's. From the time when the fonts list was limited to pica (+ a few), footnotes were just THERE. They had to be, because the bulk of documents came from universities where attribution of sources was (and still is) paramount. Now it is as though the Arial font had been omitted from the fonts list. If it had been omitted, would there have been claims that "you can't do everything at once" or "if Serif waited till everything was available, we 'd still be waiting" or "different people have different priorities" or .... ? Alternatively Serif could have chosen to leave the option to flow between frames until a later date - but they didn't do either of these things, because they formed part of the standard (taken for granted) DTP package. I just do not understand.

same here. I ended up with ID again, I only use Affinity Photo regularly by now, but for side projects mostly. it was a shame, because I enthusiastically managed to convince many people to jump to the Affinity package, whereas these feature omissions are rather offputting, once you have to start referencing stuff and keep track of them. I check these threads from time to time, hopefully we'll get a notification that footnotes/endnotes are included in the next beta. this thread reminds me of the infamous "select same" one, so I accepted by now that my use case is not the target audience for serif.:)

It seems different from what I read in you second post: In this case, it wouldn't be a package containing all the items for a specific brand, but some sort of template able to use colours/logo/fonts/etc. depending of a brand? Like having one template, and on a click it would be automatically branded for Adidas or Orangina?

If not installed, but read and accessibles when the document is open, it would be better. Avoiding cluttering the asset or swatches panels. And if possible, being able to add swatches or assets to the items, with an option to automatically update them (sort of like the slices), could be a nice addition. In fact,it would be like the package folder was like a folder, once exported.

You can use a font in an Asset, butt Joe but how do you define one in an Asset such that a user can create texts using that font? It sounds like the idea is to have a collection capability that lets you define and package and transport everything for a brand. That would require having the full font definition so other designs can use it for whatever text is needed. Assets can get you part of the way, with logos. And Templates can get you part of the way. And .afbrushes and .afpalettes can get you part of the way. And font files. But that's complex, so a nice packaging mechanism that can handle all of it would help.

It's not so much collaborating on a single file on a single project but being able to package something that could be opened up later by someone else. In my case it's translation work on brochures. At the end of putting in the translation, I'd like to save in a file format someone else can open. I work for a global charity, I can't mandate they all use one design package or our contractors - or at least it will take time.

@Old BruceIt's certainly not needed for every use case, but the example I gave above directly addresses your question. In that set of 50-some documents, I do indeed have things that need to be on each and every spread (cutting guides, background textures, etc.), and I need to turn them on or off individually when printing/exporting to generate the several variations of output from each document which comprise the package of digital files I sell.

It's not "applied" per se. It just exists as the structure on every page. I have an old post somewhere outlining my particular use case, but in simple terms…I am a package designer, snack bags mostly. In my usual design, I have a Master for the front of the bag and a Master for the Back with common elements. On each individual page, there are unique elements corresponding to product in the bag. Also on each page, front and back, there is a product window in 2 forms, 2 identical shapes/curves: one is a simple spot color fill called "window" which the printer uses to make the transparent plate, and one contains an image of the actual product along with additional graphic elements to make the product look "realistic" within the window (shadows, highlights, etc.). These graphic elements vary somewhat between product since what is "in the bag" is different for each. At one point in the workflow, I need to export the bag artwork with an actual image of the product visible in the window for the purpose of making 3D renders. At the later point of the flow, sending the art to the printer, I need the product image to be hidden. In this simple example, hiding the product image itself is relatively simple: I turn off that layer in the Front Master and the Back Master. However, since the additional graphic elements are different on each page, they are not attached to the Master. I would have to go to each page and hide them separately. Life be be much easier with a single Global Layer called "product window" that could be flipped document-wide and hide everything I need hidden/shown.

Also, the package shouldn't look at modification in the fonts as it is (time stamp of the fonts' files), but should use the version of the font a comparison, since that's what can cause troubles.