Jump to content
You must now use your email address to sign in [click for more info] ×

Thomas Ganter

Members
  • Posts

    23
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Callum Haha – and us AppStore users will have to wait until … when exactly?
  2. d’accord. I was thinking about this as well – there's the PRO and CON to weigh with Assets. That approach would be obvious (and should be supported in parallel!) but then there is always the chance of just missing to send those documents along when sharing the file. Also, there is always the Font license issue -- having the fonts in plain sight makes piracy so much easier (don't want to use the word „encourages“ though). Having fonts embedded could be a one-way route (i. e. not make them "exportable" again) and all rights are maintained (assuming you have a license for the font in the first place). But, for the avoidance of doubt, a "document fonts" folder should be supported as well.
  3. Hello world! I do publishing as a hobby. Pro bono as a volunteer for parishes and communities. But as a result of that I have many different established "identities" to support, all with their own Colour Schemes, Layouts and typography. Colour Schemes and Layouts I can manage using Paletes, as can I typography -- but not associated fonts. Current solution is to either have all fonts always installed on the system. This is a mess, and it slows down my system and makes the font dialogs unwieldy. Alternative is using a font manager. This is also a mess, since none integrates well with Publisher and it is a painful manual exercise every time. Also, both solutions are not "portable" in the sense of "trans-portable". Thus, after long intro, here my proposal: Make Fonts "importable" like any other asset. Just import document fonts and make Publisher (and the other Affinity Studio applications for that matter) retain the font files in the document bundle so they are sent along onto other platforms. And they are automatically enabled when the document is open. And automagically do not show up anywhere outside the document. Clean, simple solution. Transparent to the user. Failproof. Robust. Intuitive. Community -- what do you think? Greetings, --Thomas
  4. Yes, I know about this Studio panel, but never understood it's purpose because the "styles" in there are immutable. And they are way uuuuggggllllyyyy. IMHO, that is.
  5. As found out in this question over in the Q&A forum, Publisher does not support an equivalent to what InDesign calls "Object styles". However, to produce quality output that is consistent, this is a mandatory must-have -- styling would otherwise be so much more tedious and error-prone.
  6. OK, then, please make this a very urgent feature request. This is mandatory if one wants to create a publication with a consistent look. UPDATE: Feature Request posted here.
  7. Hello world, In laying out a newsletter I have a load of elements that should look “the same“, i.e. consistent. Like the Layer Effects (shadow, glow, blurr), or the stroke thickness/style of a Frame or Box. So that, once I decide that a 10px shadow is too bold, I only would need to change one style instead of 30-odd individual boxes. In InDesign these were ObjectStyles, and they were powerful … in Affinity Publisher I fail to understand how the same could be achieved. Please advise/ help. Thanks! --Thomas
  8. Hi, maybe this is also a misunderstanding becaue I am so much InDesign-indoctrinated, but I have problems managing colors. I have created a color swatch palette for the CI colors of our parish and use that to assign to elements in Publisher (text, frames, fills, stokes, ...). Now, in InDesign, once I change the swatch all objects that use the swatch will be automatically updated. In Publisher, this does not work. So, either my expected behaviour is wrong (user defect). Or the expectation is justified and I'm too dumb to correctly use it (user error). Or it is indeed a bug. Which one is it? --Thomas
  9. just for clarification (because I get these warnings exery single time): How would I *find* these instances of hidden text? Especially in a large document with a lot of frames ...
  10. Hi Dave, thanks for the update -- and briliant that you have a fix (assuming 1.8 is not too far into the future). I *think* have have worked around all these issues (found a few more along the way but was to pressed to post here -- maybe I will once I have reproduced it). Now I need to just carefully review all 48 pages visually to ensure no unwanted side effects allear. Greetings, --Thomas
  11. Hi thomaso, I did upload the file and all the fonts used (without the graphics) for Jon P from this forum a few days ago. I am happy to re-upload the current version of the file if you send me a dropbox link. This is a parish newsletter, so no secret content or anything.
  12. Some more experimentation here, and it seems to be driven by a) either the fact that I use text frames from the master page, or b) re-flowing text around another, linked text frame (heading text frame accross the full spread, copy text frame being reflown) See Video for a demonstration. Bildschirmvideo_aufnehmen_2019-08-17_um_10_40_04.mov
  13. OK, I have to revert my previous statement. This now is a production-blocker for me. See the attached video for a demonstration, this is utter ridiculous and I fail to see how I would be able to work around this other than *manually* flowing text (but then I can also switch to PowerPoint for my Publishing needs – there would be not much difference). Please *urgently* help. Bildschirmvideo_aufnehmen_2019-08-17_um_10_24_02.mov
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.