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

rcheetah

Members
  • Posts

    51
  • Joined

  • Last visited

Posts posted by rcheetah

  1. spacer.png

     

    Sorry for being absent so long. I had my settings misconfigured, so I didn't receive any notifications.

    Well, this thread escalated quickly. There seems to be more bugs related. I don't know of how much help I am at this point. Do you need anything from me? To be honest, a lot of things discussed went a little over my head. I just realised, that Affinity has a lot of troubles with embedded colors, and maybe even from other affinity suite files.

    I come from Adobe, and I still use it daily as a professional. I use Affinity only for private projects, and this is not so  often the case. Every time I try to do something, I become very frustrated, because things just won't work. Some of this are missing features (e.g. still no raster vectorisation for designer …), some of them are like this just bugs. I understand I have a hard time because it's a different software, and I have to get used to it. But often it's so utterly frustrating. I was completely in rage when writing the original post, that's why it was so straightforward. I used all my focus to not be impolite. 

    In my workflow, I mostly create the designs in one file, and when I print them myself, I montage them in a different file by placing it in there. In this case I printed on labels, so I wanted to save space, and put everything on one page. Of course I wouldn't waste three A4 pages of label paper by printing each design separately. So exporting print-ready designs with crop marks and placing them into a new A4 file is my workflow for this, coming from Indesign. This way I don't have to create the cropmarks myself, and have the bleed for cutting it myself. Would you suggest a different workflow? If not, which export and import options should I use for this workflow?

    Aside from my workflow – as you figured yourself – Affinity clearly has a lot of bugs with this sort of stuff. So this would really need fixing. Color management and placement of files seems to be a pretty core thing, and this is Affinity 2.0.

  2. I have a huge problem. I can't export PDFs for files that include PDFs. They will not get cropped correctly when exported, but are completely messed up and missing their cropmarks. 

    When doing the same in Designer, they're already wrongly cropped in the software itself, even when I use .afdesign files. 

    Everything ist in Affinity 2.0, also the files. 

    I'll attach a screen video, so you can see for yourself. 

  3. 2 hours ago, MikeW said:

    Unless client proofs need generated during writing and they can't handle those unstyled elements, just run the f/r before a generated pdf. Else wait until the final is done.

    Consider saving expressions and/or f/r searches in a text file. I do that anyway and keep it in the project folder. Even for ID.

    Yes, there are of course possible workarounds using find and replace. But this is not a clean workflow, and very error-prone. Let me tell you a real-world example for this feature. This was a situation I had to deal with: 

    For a cruise company I had to do a lot of catalogs. The font I used had the ligature “ff”. Now we wanted to have ligatures enabled, buuuut: German has this wonderful long word “Schifffahrt” (cruise), which has a triple-f. Now there would be a ligature ff followed by a normal f. And the client didn’t like how this looked. So we had to avoid ligatures on triple f’s. Due to the nature of a shipping company, this word would appear considerably often in their catalogs. Having worked with a reasonable amount of paragraph styles (that inherited from each other), I was able to apply a GREP style to texts that use this font. The GREP style applied the character style “no ligatures” on every occurrence of “f{3,}”. And as we copied our styles from document to document, I was able to just forget about this problem forever. InDesign handled it for me in dozens of documents that I made for this client. 

    This may sound like a very particular case, but I use GREP styles very often in my daily work. It’s a very helpful feature. So they’re definitely something worth working with. I couldn’t really just replace that practice by using search and replace. 

  4. On 8/6/2019 at 6:17 PM, jrkay said:

    I assume that this is a suggestion by an apple user, if it GREP is already implemented by Affinity, how would this be of use and relevant for a Windows user please?

    I can’t really answer that, because I really don’t understand the question. REGEX has nothing to do with the operating system. It’s a way to describe complex searches. I suppose it is implemented for almost any operating system (Windows, macos, linux derivates, …), but I also guess that Affinity uses its own modified regex-engine, so it wouldn’t be dependent on the OS and so it can access all the information about the text (like styles). 

    On 8/6/2019 at 7:18 PM, walt.farrell said:

    The request was not for regex-based Find/Replace, which already exists.

    It was for defining Text Styles based on regular expressions, which would (I believe) allow you to say "whenever I create text content that matches <some regular expressions> assign <some style name> to it automatically".

    correct

  5. 5 hours ago, walt.farrell said:
    
    (?-s)^.* {4,}.*$

    The (?-s) at the beginning prevents "." from matching the end of line/paragraph. And setting that option also seems to remove the need to make the ".*" non-greedy.

    Thank you very much! This pattern does work now :) although I still don’t understand why. 
    Would you be so kind to explain
     (?-s) to me? Does this have a name? I couldn't find it in my regex cheatsheet. Is it something specifically for AP? I’d like to understand it, so I can prevent similar mistakes in the future. 

    Also does this mean $ not matching a paragraph ending is intentional behavior? Or is it a bug? It seems pretty odd to me. I would totally understand if it doesn’t match a wrapped line obviously, and also if it would not match a line break. But not matching a paragraph break seems absurd to me, I simply don’t understand this behavior. 

  6. Thanks for your answer. I should’ve mentioned that at point 3: I actually tried making the operators lazy like in your pattern, but it doesn’t work either, as $ doesn’t match the paragraph ending. Now it strangely selects only one line of text and one line of chords, although every line has a it’s own paragraph ending.

  7. Thanks for your answer. Sadly, it still doesn’t make sense to me:

    1. I have a paragraph break after every line (in the result you can even see the pilcrow signs). So as you stated the $ should match that.
    2. This is pretty normal for grep, as . matches every character (if it’s not in one-line mode)
    3. I understand, that the standard is greedy. But even if I make the operation lazy as you suggested, the problem is still, that $ doesn’t match the paragraph break, as it should.

    If I’m still misunderstanding the concept, could you maybe write me a pattern that does the job correctly, so I can understand how AP’s GREP interpreter is different?

     

    Edit: I attached the file for testing purposes. 

    Chords Test.afpub

  8. When I use GREP search, and define that I only want to find whole lines by using the ^ and $ signs, this will get ignored. 

    In my case, I try to format guitar chord sheets, and give all the chords a pre-defined format. I try to detect the chord lines using following GREP pattern:

    ^.* {4,}.*$

    Although this may not be a perfect pattern, it mostly works, as the chord lines include a tremendous amount of whitespace. This pattern works perfectly in another GREP search I tried. As I specified, I only want to match one line from the beginning (^) to the end ($). When I use search and replace in AP, I get the whole text as a single result, because it includes all the line ends. See attached screenshot. 

     

    Bildschirmfoto 2019-07-21 um 21.42.29.png

  9. On 8/30/2018 at 3:28 PM, Peter Werner said:

    You could just enable the write protection option in Finder/Explorer for a regular publisher file that you want to use as a template, then it won't save over the original by accident.

    I would also prefer templates over write-protection. Sadly, mac os handles write protection pretty strangely. E.g. you can't move a folder that has a protected file inside. It’s not like write-protection but more like a complete lock inside the file tree.

  10. I think scripting support would be a wonderful feature. I would love a good documented API, maybe even a well done scripting environment (persona?) with an included library/documentation.

    As of languages I would prefer something fast to write and easy to read like python, maybe even something eloquent like ruby. Javascript has a hideous code structure (things like }); are completely normal), though there are also many pros for JS. 

    But maybe think about making scripting more accessible for the average user. There definitely are ways of doing this, if one is willing to go there. Drag and dropable scripting may be possible, or even node-based programming like NodeBox. 

    Well, this should of course not replace normal scripting, but extend it and let more users be able to use the capabilities of scripting. 

  11. 5 hours ago, v_kyr said:

    if you have an urgend need for it (tracing), you have to use workarounds or third party software to overcome.

    I don’t have an urgent need for now. My copy of Adobe Illustrator CS6 is still working, so I can trace there. But riding two horses at the same time wasn’t what I hoped for when I bought Designer. For me and my workflow I need image tracing when working in vector software, and I seem to be not the only one. It is a key feature, and thats why I join the plead for it, and hope that Affinity will hear us. 

  12. Thank you for your response. In general, those are good hints. But I think it doesn’t diminish the point I’ve tried to make. I shouldn’t need to switch software for such a step. 

    24 minutes ago, v_kyr said:

    The Potrace CLI (command-line) tool follows old Unix traditions, where a bunch of commands are often piped together. So an ImageMagick conversion can be routed through that one and the like to vectorize some rasterfile.

    I thought so, but that just illustrates my point, that this is very complex for the average user. Even those who maybe work a little bit with the command line (those who don’t fear it in general) will get frustrated trying to pipe commands together. It is an option for developer folks, but not for an average user. And by the way: I tried to install a fully working image magick a few months ago, and it was also not very pleasant.

    24 minutes ago, v_kyr said:

    In order to deal with this in a more comfortable manner, one can use the DragPotrace GUI tool (english) which loads JPG/PNG etc. directly for tracing.

    Good software tip. Sadly it doesn’t run on my mac os version. 

    In general I think that using a ton of different software for different tasks of a workflow is at its core against the philosophy of Affinity. All the more if I think about yesterdays presentation of StudioLink. So I don’t really understand why Affinity is so reluctant to integrate it unless it’s in their eyes perfect.

  13. Okay, this may be an unpopular opinion here, but I think even an okayish image tracer included in the software would be better than no tracer at all. There would be no harm licensing potrace for now, which seems to be one of the best quality tracers atm, and implementing an even better tracer once Affinity can work it out. I think for a professional vector software like AD, an image tracer is a must-have-feature, just as embedding objects in text flows was in Publisher (which we actually got with the published version).

    I like Inkscape – actually I worked a lot with it in past days – but using it on mac os gave me a lot of headaches. xquartz software usually doesn’t seem to work right. 
    If you get to install Inkscape on mac it at all. For example at this moment the homebrew way is broken and there is no dmg for the current version. And you cannot expect the majority of people being able to compile it themself and deal with tons of compiling errors. 

    potrace on the command line will be to hard to swallow for most people. Also according its documentation it just works with pretty wild image formats (PBM, PGM, PPM, or BMP, which the latter one is the only one I know and I haven’t used it for over a decade). So you need to convert the image first (with another piece of software that is able to export this strange formats), then vectorize it and then import it again.

    Depending on the workflow, image tracing can be a common working step. You may need about 10 or 20 images traced. So to conclude I cite myself: “even an okayish image tracer included in the software would be better than no tracer at all”.

×
×
  • 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.