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

Search the Community

Showing results for tags 'text import'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Affinity Support
    • News and Information
    • Frequently Asked Questions
    • Affinity Support & Questions
    • Feedback & Suggestions
  • Learn and Share
    • Tutorials (Serif and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • V2 Bugs found on macOS
    • V2 Bugs found on Windows
    • V2 Bugs found on iPad
    • Reports of Bugs in Affinity Version 1 applications
  • Beta Software Forums
    • 2.1 New Features and Improvements
    • Other New Bugs and Issues in the Betas
    • Beta Software Program Members Area
    • [ARCHIVE] Reports from earlier Affinity betas

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL



Member Title

Found 3 results

  1. New here — not much luck yet with forum search. If there's a discussion about this, apologies for not having found it. Back in the Neolithic I used QuarkXPress, which supported a tagging method for text import: Simple codes embedded in plain text were transformed into complex formatting during import. The competition didn't have such a feature at the time. It was among several reasons for QXP's becoming the program of record for book pagination (until InDesign came along). Even years before microcomputers took over the world, the typesetting systems I used had tagging and translation-table features. Same purpose: Prepare text containing simple codes, then get complex formatting during text import. The machines' CPUs ran at glacial speeds compared with what we have now. But the text-import systems were fast and efficient. It's orders of magnitude faster than importing plain text into a design/pagination program and then hand-formatting it. Search/replace is not efficient unless a program supports complex search/replace enabling it to find starting and ending tags and formatting text located between those tags. Even at that, having to do it repetitively is tedious and time-consuming. (If search/replace can be controlled via scripting, that certainly helps.) Manipulating text outside the pagination program is inherently more efficient. It can be done with powerful and fast tools ideal for that purpose (Python, Perl, Ruby, and so forth). Affinity Publisher looks like an excellent contender. It too needs this kind of feature. If the company has no such plans for the near future, I hope the program has a plug-in architecture enabling a third party to add this functionality. To anyone importing a lot of text, that kind of automation is worth paying for.
  2. I've had some difficulty using Find&Replace to apply styles to tagged text on import, but found a solution that worked. This is somewhat more involved than the Find&Replace recipe which has been posted on several threads here, and may help someone with similar difficulty. Publisher My import text is a very simplistic HTML-like structure with free line breaks, which Publisher imports as paragraph breaks. <h1>This is a sample header</h1> <p> This is a line in a paragraph, which continues on a 2nd and 3rd line. </p> When I place such a tagged text file (.txt) in a Publisher text frame, the first thing I do is find and replace all the paragraph breaks with single spaces. Find: para-break Replace: space Obviously the actual paragraph break and space characters are used in the RE patterns, but I'm spelling them out here to be clear. Then I use an RE that captures end tags together with any surrounding spaces and replaces them with the end tag, spaces stripped off, and adds a paragraph break. Find: space*(</.*?>)space* Replace: \1 para-break Then for each tag, I use an RE that strips off the start and end tags and any superfluous white space and applies the appropriate paragraph style Find: <p>\s*(.*?)\s*</p> Replace: \1 (Format with Body) Similarly for <h1> and Heading 1 and the other tags. So, why did I do it this way? Why didn't I just strip off the tags and superfluous spaces, apply the styling and add a paragraph break in one step, combining my 2nd and 3rd Find&Replace steps? The answer is simple: It doesn't work! When I apply the 2nd tag style, the style is also applied to the adjacent paragraphs previously converted to the 1st tag style. I tried both "para-break \1" and "\1 para-break" as replacement patterns, but neither leaves the previously converted text alone. The solution is to introduce the paragraph breaks first to separate all the paragraphs cleanly, before styling each paragraph. Trying to chop out paragraphs and style them at the same time using Find&Replace is not "stable", at least in this version of Publisher.
  3. Dear all, I've encountered a problem when importing PDF files into Affinity Photo and Affinity Designer. The dashes imported are covering a part of the following letter (See first attached picture, second picture is how it shou). The result of this is that I need to change all the old dashes to new dashes manually, which is getting very tiresome if having more than 20 objects per figure. The PDFs are created in R if that matters. Is there any way of solving this issue? Thanks for any help! example.pdf
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.