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

Frank Jonen

Members
  • Posts

    382
  • Joined

  • Last visited

Recent Profile Visitors

2,500 profile views
  1. Pretty much every publishing house is looking for ways to reduce overhead. The first who makes a good enough effort in this space, wins.
  2. The thing is, this is really easy (I wrote a basic parser that uses frontmatter). Publisher has all the building blocks for it. Yet for some reason they keep deciding against it. My experiment with MD in in Publisher was leveraging that. I used the data import for JSON files with veeeery long strings. Each section was stored in its own string value and each chapter as a separate file. The Affinity RegEx limitations ruined it though. You can't automate anything, you have to launch each element replacement and each markup deletion manually for each element group. Takes forever and is error prone. Hence "not worth the effort".
  3. I've done that in the past a few times but it's really bad in Publisher. The end result was so bad that I ended up skipping Publisher altogether for that project. RegEx just isn't well supported for automated formatting. Removing the markdown syntax is another thing where Publisher caused errors. It's a lot easier to write a basic Markdown parser in Rust than to get Publisher to behave properly with RegEx. The time spent isn't worth the result.
  4. You might like Typst and since Pandoc 3.1.2 there's a path from Markdown to Typst. It's a bit easier for hired editors to work in because of the browser based UI. The template language has CSS ideas as its base. Affinity probably plans to do what Amazon does "…we're seeing an increase in requests for Markdown support. … In the meantime you can use the export function of your Markdown editor to create Microsoft Word compatible files…" Basically try to wait it out for several years like Microsoft did with the Internet.
  5. Going for perfect is the only way to arrive at good. If you're only going for good enough, your best result is going to be mediocre.
  6. That makes it the perfect case for a linked document. If not THE use case. Application and System palettes don't need linking because they are in this state by default. Linking actually only makes sense for Document palettes.
  7. I just tried that but it doesn't do anything as the palette already exists. I'd have to start over with the project for that to work. Also weird that I can't duplicate Document palettes. What's up with that? Back in my Adobe days that was my go-to tool for creating color themes.
  8. Why even have it in the menu when it's not functional? There are nicer ways to advertise an upcoming feature.
  9. @Bryan Rieger Export Persona only handles single page stuff and I had some problems in the past with Export Persona not being that reliable with EXRs. I have a few Publisher documents too that would become a nightmare to work with if I'd use Publisher v2 for it. Skydomes in various states for example. Publisher so far was great to manage HDRIs that only need a few elements changed between each version. Now in v2 it's unusable. Same with texture sets. I was able to keep everything tidy in one place, export the pages all in one go and be done. Not possible anymore. It would take forever.
  10. Should be optional. For my use, I compress from an uncompressed, flattened master file. Saves a lot of time. So there that'd hinder me as well. For people who want to go straight to final and tinker around with each image, it could be useful to wait around and fiddle. It doesn't even have a region of interest selection, you always have to wait for the entire layer stack to render. I now shudder at the prospect of having to do actual work in Photo which also has this crap now. I have composites of several GB. If I have to wait for that shit, I'm done with Affinity. That's atrocious.
  11. Not true. I'm getting a beachball with every element I click on and have to wait. A process that shouldn't even take 5 seconds, takes minutes. I haven't seen a single preview yet, just the spinning fan in the preview window while the beachball annoys me in the settings.
  12. There's no reason why it can't work with the auto-reflow within the active document. The need to generate a new document to evaluate the dataset just feels clunky. Like using a Microsoft app from the early 2000s. Generating new documents should be optional for the few people who generate entire catalogs with it. But even there it would be faster to see what you're working with.
  13. This should've been in the previous release but here it is again. Markdown import so we don't have to convert to legacy formats or use crude copy & paste for each article. Solution: Link Markdown files to text frames like the data merge preview. That way the documents can be worked on by writers/editors and kept up-to-date via the Resource Manager.
×
×
  • 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.