CarlM

I've always thought of Studio Link as enabling me to do those tweaks that it's a pain to go back and load up Photo or Designer to do but for things that require more work wouldn't it make more sense to open the image in Photo to complete?

Fantastic! The Pin to Text issue is resolved

I agree. Irrespective of whether it is a document or image there should be consistency. All linked files whether up dated externally, using persona or by publisher itself should affect teh original. Embedded files should only affected the embedded object. There's probably a coding reason for the inconsistency but I've no idea what.

Strange. I've found 471 to be really stable and I've not had a single crash - yet. The issues are a return of the pinning problem which is a nuisance while I'm working on my current project which has a lot of images within the paragraphs and need to be pinned but most other reported problems haven't caused me any issues.

I think Jon is referring to the 1.7.2 471 update.

The other reason may also be that the engine underpinning the Affinity range shares the same codebase for both the Windows and Mac versions. It would mean creating two separate sets of functions to call spell checking for Mac and Windows whereas using Hunspell probably simplifies things by enabling the same calling for both. Much other software does the same thing using Hunspell but doesn't necessarily make it obvious.

I agree with fde101. We're moving onto another aspect which is profiling printers and that is another thing entirely. I use an agency to generate printer profiles for my printer/ calibrated monitor combination which gives as close a match as you can really hope to get. I agree about Pantone Color Bridge - it's normally a close enough match. As a photographer it's important for me to be able to provide consistent output for my clients - most of whom are book and magazine publishers and being able to print an image to a similar spec when required without having to resort to a professional print house for the odd image is useful. the same applies when producing output on Publisher - the ability to print out a hard copy on my printer and having a reasonably close match to the screen image is a bonus. The point ultimately is that you can never achieve more than an approximate match and part of the skill of working in front of a computer is to be able to anticipate the difference and allow for it when selecting colours.

The only issue there is that you then really need an extremely expensive Pantone Swatch book (the one that matches the colour set you are going to use) so you can check what the Pantone colour will actually look like when printed. It's the strength of Pantone but the cost is its weakness.

The only way to properly calibrate a monitor in the first instance is to use a colorimeter. To be honest the Mac and windows in built tools aren't any use and can't give you more than a vague nod in the right direction - they're not quite worse then useless but nearly. Palatino is quite right use sRGB unless you can properly calibrate your monitor. The two issues encountered on most monitors is that the colour temperature is set too high - usually at 9200K when it should be set to 6500K which is much redder than most people are used to but will display an image that is nearer what you will see on paper. The other issue tends to be that users set the brightness and contrast too high (or they are set too high as factory defaults). this will affect your perception of colour intensity and brightness to an unrealistic degree. Don't forget that there is a different between transmitted colour from a monitor and reflected colour from a print. The two are completely different ways of looking at colour and is the basis of colour theory. What it all boils down to is that if you want to be able to reproduce what you see on screen in a print then you'll need to do a fair bit of work and possibly invest in a colorimeter like Datacolor Spyder or Colormunki.

I think you may have misunderstood me. I was being critical of those users who expect a fully formed product on day one and also want features that bear no relation to a Desk top Publishing application. what I was saying was that just because you can do something in a totally unrelated program it doesn't mean it is a reason to have it in Publisher. It's like expecting your local bus to also have wings and fly you to another country as well as drive you down the road to go shopping.

It's not really about abandoning loyal users but the PagePlus code base is hopelessly outdated and it made no sense to continue trying to flog what had become a dead horse. The alternative path for Serif was to produce an engine that could be ported across two incompatible platforms (Windows and MAC OSX) and use the same code base for 3 different applications making their files cross compatible - something quite ground breaking. That meant it wouldn't be reasonable to spend time and resource to create a reasonable conversion from the PagePlus file code system to the new .afxxx format. If it is possible and financially viable then my guess is that a 3rd party coder will reverse engineer the pp9 file format and produce a converter. Of course you don't need to use templates to create a document. You could also build it from scratch - it's by far the best way to learn Graphic Design and you can just as easily copy what others have already done to create your design.

Work your way through the requests forum. In the past couple of weeks there are at least half a dozen requests for or complaints that Publisher doesn't do something that some inappropriate non-DTP related app does and which wouldn't apply in a DTP in the first instance.

I previously reported in one of the Betas that the Pin to Text function didn't work on pages in Text frames that had been created in Master Pages. https://forum.affinity.serif.com/index.php?/topic/95209-pin-to-text-bug/ It looks as if the Pin to Text function is now completely broken because I can't get it to work at all. Select the function then try to move the marker to a new location as in the screen capture in my previous post and and it won't move. It doesn't make any difference this time around whether the image and text are placed in a new frame in a page or in one created in a master page. I've edited this because after testing a few times there is a bit of an anomaly. The problem has returned exactly as previously reported (and fixed in one of the betas). The failure to work on a new Text frame created in a normal page seems to occur intermittently. I'm not sure if it's caused by having another document on a tab in Afpub at the same time, if that document having been created in an earlier version makes a difference or if it is another factor in play.

It's telling that Serif opted to write the code for their three flagship products from scratch and re-launch them as Affinity. It demonstrates an understanding that now and again you have to take the plunge and start all over again rather than keep patching and increasing bloat in a product to produce something that is future proof. It never fails to amaze me how many posters predict the demise of Affinity publisher because two months after it's launch it not only doesn't do everything that ID and Quark do after 20+ years of development but also doesn't do things that 20 other apps that aren't DTP are capable of.

The issue really is about use of language. "Prefer Linked" infers that the preference for new images would be to link unless otherwise specified. Consequently, I would expected images that were already embedded in a document to continue to be embedded and, if I were to update the file, to continue to work with any embedded images as embedded unless I manually changed that. I have to ask the question why would you change the default preference midstream? It's the sort of thing you would make a note of doing before beginning a project, surely? I'd also question the value of "extracting" embedded images from a file. It all sounds like poor preparation and planning before creating a project. Which leads onto how do users start projects? Just running around with no file organisation could be a recipe for creating problems. Personally, I write a set of project notes before starting so I know what I need to do and what is required. I create a project folder and copy any documents or images into it. I use "Prefer Linked" by default and as all my files are in one place there's no problem. Any adjustments I need to make to images are normally specific to my needs for the project so I'm happy for the original image to be elsewhere and left untouched.

SVG and EPS are the best formats for cross application working but if the agencies you work with want AI files you can try using one of the many converters available. https://www.google.de/search?q=svg+to+ai&ie=utf-8&oe=utf-8&client=firefox-b&gfe_rd=cr&ei=s78FWYapBeKA8QfanrDQCw&gws_rd=cr

I think that you've identified a bug and should report it as such. If you have a space or tab before the sort return then the line should simply justify left - that would in my opinion be the expected behaviour. If you place a soft return at the end of a word then it should justify according to the paragraph style. Word word word word Word word word >soft return Word word word Word word word word Word word word>soft return Word word word

I agree. I encountered the same when I first started using Publisher last year and it took me a while to figure it out. Try ticking the "ignore Baseline grid" box from the Text Frame Studio panel.

Pretty sure it's a bug. I recently reported another issue with Spell checking in Text Frames created in Master Pages. That was escalated and resolved in Beta 422 and my guess is it's related. https://forum.affinity.serif.com/index.php?/topic/93577-publisher-spellcheck-bug/

"Pin to Text" works fine when working with images in text frames created on the page but when pinning to text in pages using frames created in the Master pages the function sticks resolutely to the default position Publisher first applies in the frame. I've attached a screen capture video to demonstrate. 2019-08-11 12-16-56.mp4

Pageplus was a really good PDF creator and better than Acrobat for creating forms so there's no reason why Publisher can't as well. As Roger says it only needs a little tweaking :)

I can reproduce it in 1.7.1.420. Align the text away from, towards the spine, align right, centre, or left, and it doesn't happen. Image to the right of text & justify left, centre or right and the spacing problem occurs. Image to the left of text & justify left centre or right and the spacing problem occurs.

Thanks. Publisher is the 1st application I've been excited about since 2006. Time to buy Designer

I reported this bug in the Publisher Beta forum a week ago and didn't receive a response. It is also a bug in the retail version 171.404. If I use the Place function to import text into a publisher file, the auto spellcheck identifies words not in the dictionary but is unable to add those words using "Learn" It cannot "Unlearn" either. The History shows that even if the word is fully highlighted it isn't being detected and Publisher records it as an empty string. This only seems to occur when the Text Frame is created in a Master Page and not when a Text Frame is created on a document page. Publisher Spell Check Test Doc.afpub Publisher Spell Check Test.docx Extra - Learn doesn't work at all on pages in Text Frames created on Master Pages - Major bug in my view.

I've now discovered that Placing an MS Word .DOCX file into publisher Text frames results in the same problem. I noticed it when going back through the pages trying to correct some red underlined words. To test it I created a new document and placed the DOCX file into the frames. I even added in a couple of words that weren't in publisher dictionary and attempted to get publisher to "Learn" them. The result was exactly as in my previous post. The text frames were created in a Master page - if that helps. This is a bit of a deal breaker unless its something I'm doing wrong in which case someone please tell me what I've idiotically done wrong. Extra - Learn doesn't work at all on pages in Text Frames created on Master Pages - Major bug in my view.