Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by A_B_C

  1. Hi everybody, I am experiencing quite a few problems to get my designs from Affinity Designer to FontLab. Theoretically, I would expect that things would work like in this video (have a look at 1:32 onwards): https://www.youtube.com/watch?v=h2sJiFcOm-8 You can paste drawings directly from Illustrator to the FontLab sketchboard. Unfortunately, that doesn’t currently seem to work, or rather, drawings are pasted as pixel images to the FontLab sketchboard, regardless of selecting “Copy images as SVG” or not. But then there is the option of saving a drawing to EPS and importing it to the FontLab sketchboard. Unfortunately, the results are somewhat odd, and I don’t know what to make of it. Firstly, not all of the export options will produce an EPS file that is recognised by FontLab. “Save for Print” creates an EPS file that is recognised, whereas “Save for Export” doesn’t work. I think it has to do with the relative coordinates, but I don’t know. Secondly, when the import works, the result looks incredibly strange. Importing an Affinity Designer document showing a simple cross will end up with the result shown below. In a way, I like the result, but it is clear that you cannot work this way. Again, I don’t know what to make of it. So is this a problem of Fontlab or of the EPS export algorithm used in Affinity Designer? Any advice would be greatly appreciated … Alex Cross.afdesign Cross-For-Print.eps
  2. For me, they are disastrous. There's nothing more terrible than software making these kinds of decisions for you, without affordances to prevent it. On the other hand, you will also have to admit that it is very cool to be able to just drag an object to an artboard and have it immediately nested as a child to the artboard node in the document structure, at least in use cases that are different from the ones you have in mind. I can perfectly understand your frustration, João, for designers of info graphics will need the functions you described. You cannot really do maps without global layers. You should have a choice. So, again, I think you are justified in your criticism, and I would endorse your request for a second look and some sensible tweaks.
  3. Personally, I wouldn’t call Designer “dumbed down” or its UX results “disastrous,” as they work pretty well for a whole lot of scenarios. And I also understand that the developers are reluctant to make changes that are certainly of the far-reaching sort. But apart from that, I am clearly seeing what you are after, and it makes a lot of sense to me. There is also the parallel, still unresolved problem of “global layers” in Publisher that is a real hindrance in some use cases. So I fear there is still some conceptual work lying ahead … https://forum.affinity.serif.com/index.php?/topic/66164-wrong-layer-concept-for-an-layout-application/ https://forum.affinity.serif.com/index.php?/topic/66333-publisher-some-thoughts/ But it seems that global layers are on the roadmap already: https://forum.affinity.serif.com/index.php?/topic/66164-wrong-layer-concept-for-an-layout-application/&tab=comments#comment-400240
  4. Hi JGD, thank you for these annotated screen casts. They made your points perfectly clear. I would also endorse your point that the container model of the artboard should be thought of as being reconcilable with your “universal layer” model. As an aside, you will know that it is possible to achieve what you want by creating, not universal layers, but universal artboards on top of empty ones that are supposed to act like their namesakes in Illustrator (see attached). I haven’t followed all of your threads, so I am sure you already considered that option. But I must confess, this technique is also a bit cumbersome and creates a slight mess on the workspace. Test.pdf Test.afdesign Personally, I must confess I have always been a bit perplexed by the fact that independent layers above artboards get exported to PDF so effortlessly, as that clearly breaks the logic of the container model (or the “document tree” model: an independent layer of that kind doesn’t seem to have a proper place in the document tree). I must also confess that I have never used this technique, partly because of the editing problems you describe (moving “universal layers” will nest them to artboards immediately), and partly because I wanted to keep my document structure logical and tidy. But, indeed, as those little cracks and inconsistencies are already present in the current document tree model, I am also starting to wonder whether it would be possible to exploit them in a more fruitful way. As far as I understand, artboards in Designer are currently thought of as being part of a single page. For when we import a document containing artboards to Publisher, we can choose whether (a) to convert the existing artboards to spreads or (b) keep them as artboards. In the latter case, a single layout page will show up in the Pages Panel (see below), obviously containing all of the artboards as layers. Hence, there already seems to be another logical layer in a Designer document that could be a natural place for holding what you call “universal layers.” So I would like to suggest to ponder the following. What about exhibiting the “hidden” page which holds the artboards in Publisher to the users of Designer and allow them to add objects to this page? The page would then be the primary container of everything: of artboards on the one hand, being still containers in themselves, and of other objects, like layers or shapes, on the other hand. Publisher import would still allow to make a choice. When the user would choose to convert artboards to single pages, all the “universal” objects would have to be duplicated and nested to the pages according to the parts that had been visible on the original artboards in Designer. When a user would opt for keeping the artboards, well, then everything would be as it currently is. Does that make any sense? Alex
  5. Hi everybody, this isn’t a technical question in the proper sense of the word, but I would like to gather some opinions. At the moment, I am typesetting a support document for a non-profit, and I wonder how to typeset long URLs for PDF export in the best possible way. First, I believe it necessary to avoid ambiguity, in particular with respect to hyphens. By default, Publisher will add a line break to a long URL at the place where a hyphen occurs (A). But that might create ambiguity with respect to the use of hyphens in running text, where hyphens are not to be considered part of the forms they separate. Looking at (A), one might read “criticalservices” rather than “critical-services” as is intended. Since hyphens are part of the forms from which URLs are built, I would never break a long URL after an occurrence of a hyphen, but only after occurrences of signs like “/” (slash), “_” (underscore) and similar ones (B). As an aside, I believe one can also send a query string to a new line as in (D), rather than adding a line break as in (C). Now, the problem is what users do with URLs that are present in a PDF document they download from the internet. Some PDF reading applications will automatically interpret a string that looks like a URL as a clickable URL. But when I manually add a line-break where it is semantically best for the human reader, the PDF app will consider only the part of the URL before the line break as being the intended URL and neglect the part that is in the next line. When a human reader uses a PDF app that does not automatically interpret certain strings as URLs, he or she might be tempted to highlight the entire string, copy it, and paste it into the address line of a browser. But then my line break will be added to the address line as a character not permitted for URLs, and hence the URL will not be recognised. So the only solution seems to be adding a hyperlink that spans all of the lines of my URL. Unfortunately, there doesn’t seem to be a way to do that automatically in Publisher, and using New Hyperlink … will never remember the choice I made for the hyperlink type before. It will always present me with Hyperlink Type: Page first. So it becomes incredibly cumbersome to typeset a document with hundreds of URLs in Publisher. And it seems neither links in PDF documents nor links in Word files are currently understood by Publisher. They are not listed in the Hyperlinks panel, but only decorated with an underline. So there isn’t an export-import solution either. Hence, I wonder if there is a good solution for creating documents with hundreds of URLs in Publisher. Maybe someone has an idea. Any comments and ideas would be appreciated. Alex
  6. Hi everyone, recently, I have been suggesting some improvements for typesetting long URLs: https://forum.affinity.serif.com/index.php?/topic/85385-typesetting-long-urls/ As a follow-up, I would like to share a little trick or work-around. I noticed that Publisher would store every URL hyperlink I had assigned to a string, regardless of the document currently open. So it seemed the link information is stored in a document-independent way. Some research showed me that it is indeed stored in an array called HyperlinkURLs in the preferences file com.seriflabs.affinitypublisher.beta.plist which can be found at > [username] > Library > Preferences. So when you have a long list of URL hyperlinks to assign in a document, you can simply open the preferences file in an editor that allows you to edit the XML structure, enclose your URLs in <string> … </string> and add it to the array. After relaunching Publisher, you can select your URLs from the Hyperlink Properties panel in Publisher. Best, Alex
  7. Thank you very much, Adam! That was very helpful, and I am feeling relieved now. Keep up the good work! Publisher, together with the two other apps, is going to be a fantastic application. Of course, I have to add my ceterum censeo … … but I can’t wait for the release version … everyone here is excited. Alex
  8. Oh dear, thank you for the heads up! I was under the wrong (indeed weird) impression that the document resolution would somehow influence the calculation of that value. But that doesn’t make any sense, of course. I must have got some wires crossed.
  9. Just for clarification, Adam: as long as I keep my images embedded rather than linking it, I would be on the safe side, even with .330?
  10. Well, I think this is important to have, as it will allow, for instance, to calculate the “Placed DPI” resolution of an image file automatically. There might be other ways to do the necessary calculations and to ensure that your output meets the requirements of your print service, but the present implementation is something I would not want to miss, really.
  11. I didn’t mean to suggest that you could have created the new text frame to care for the overflow in a wrong way. That isn’t possible indeed. I had meant to suggest that you probably had resized the original text frame by using the wrong handle. But that doesn’t seem to have been the case, as your additional document clearly shows. I can reproduce the issue with your PDF from Indesign CS6. This is certainly serious for bringing documents to Publisher via PDF import.
  12. Many thanks for this idea! It’s a nice one. As an aside, there is no need to use an online service for this. Just drag your HTML snippet to a browser of your choice and print the page to PDF. Unfortunately, that isn’t a solution for how to typeset long URLs in Publisher. Opening the PDF won’t bring the links assigned to the strings into the Hyperlink panel. You will have to manually assign them again. I am sorry. But thank you again for your commitment and your help, Alex From-Firefox.pdf
  13. A related problem is the use of ligatures in typeset URLs strings. As long as your plain text in the PDF, not backed by a hyperlink, contains a ligature character, such as the character “f_i” in your example, Preview will only consider the part before the ligature as specifying a URL. Hence, you end up with https://www.typogra in your example, and you get a “Server not found” message. All that cries for a better solution. C’mon, dear developers, that is an opportunity to shine …
  14. Yes, indeed, as described in my initial post, that’s the main problem with adding manual line breaks to long URLs. ! !
  15. That is most certainly because you changed the size of the text frame on page 2 by using the outer handle that will resize fonts within the text frame proportionally. It’s a common issue I have seen on the forum quite often. Maybe developers should find a smart solution for preventing users accidentally using the wrong handle …
  16. I could imagine the last point to work in the following way. Add the following options to paragraph styles: [ ] Ignore hyphens for line breaks Allow (prefer) soft line breaks after [_____________________________] The first one would be a simple checkbox, the second one an input for characters. Then we could define, for instance, that the string website.com/parent-folder/index.asp?=query would not be broken after the hyphen, but only after the slashes. The query string would present a slight problem, if we want to have a line break before the question mark, but I am sure you could come up with a useful solution for that.
  17. If the Serif developers need a suggestion rather than a discussion, I would suggest the following: Add an option to automatically interpret URL strings as links as it is the case in Apple’s Pages app, for instance. Make this option a choice for the user. Don’t automatically convert strings to links. Add a highlight to links in a frame that can be switched on. Add handles to the highlight that can be dragged to redefine the string to be working as a link. See my illustration below. Make the New Hyperlink … popup remember the last settings. Define a new way to add line breaks to strings, such that copying a string containing such a line break does not copy the line break to the string. That would solve the problems with people copy-pasting URLs from PDFs to browser address lines. Thanks for considering …
  18. Oh, I know that, Old Bruce. I do understand how to add URLs. My problem is just that Hyperlink Type: Page will always (!) show up first, when I add a new hyperlink. I will always have to go to the panel menu, change the hyperlink type to URL, paste my URL, change the character style, and then … only then … I can click Okay. I really don’t know how I will be able to do that a hundred times and more. EDIT I changed my screenshot above to make my issues more clear.
  19. Well, it is just a convenience I think … nonetheless, if it is there, I assume it should work as expected … hence I reported it as a bug …
  20. Hi there, there are two issues with the Look up … command on my external screen (vintage MacBook Pro late 2011, macOS Sierra 10.12.6, external EIZO screen, connected by Thunderbolt to HDMI): The dictionary popup always appears at the bottom left corner of my screen, as long as I am not in full-screen mode. When I go to full-screen mode, it doesn’t appear at all! Please have a look at my video. Thanks, Alex Looking-Up.mov
  21. Regarding the bug, looking up words is working perfectly on the internal screen on my MacBook Pro, even in full-screen mode. It is just the external screen that is giving me headaches.
  22. @thomaso, you can also download other dictionaries to the Dictionary app! For instance, I downloaded the dict.cc dictionary, which is quite useful in many cases. It comes in two versions: https://www.dict.cc/?s=about%3Awordlist Just have a look.
  23. (Nobody seems to need a dictionary here … )
  24. The question is in the topic title. When I create a master page, for instance, with a page footer that appears on every layout page, and inadvertently edit the footer on a certain layout page, is there a way to restore just the footer frame from the master page, without replacing the master page contents on the said layout page as a whole? I believe one could add the entirety of master page contents over the already applied ones and start deleting selectively, but I wonder if there is a better solution. Sorry, if the answer should be obvious.
  25. This is smartness! Wouldn’t have though of that solution. Thank you so much.