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

nawkboy

Members
  • Posts

    29
  • Joined

  • Last visited

Everything posted by nawkboy

  1. Are there any good canned scripts for feeding TeX/XeTeX through the various machine translation services?
  2. Interesting thought to go back to TeX. I had not considered that in the context of multi-lingual typesetting. Wondering how well that will work with all the heavy figures involved. I'm not sure auto-flowed layout without tweaking here and there will be that good. Sure will be easy to run through machine translation, and will gain proper source control. What I would really like is graphical layout, coupled with semantic text markup. As I recall from using LaTeX years ago, the semantic markup was great, and layout was a pain. With InDesign and Affinity Publisher layout is great, and semantic markup is a pain.
  3. As Affinity Publisher does not currently support RTL languages such as Arabic, what are the best choices for doing so? Before happily switching to Affinity Publisher I used Adobe InDesign and paid the monthly tax. For my occasional typesetting needs, there hasn't been anything significant in InDesign that I have missed. Now I find myself contemplating the idea of an Arabic translation for some of my content, and I realize it will be a while before Affinity Publisher supports RTL languages. So, if looking to translate an English book to a few languages (Spanish and Arabic in particular), what is the best choice of layout tool? Is there any cost effective language that handles the same work being in multiple languages with minimal layout changes better than other choices? Built-in support for an initial pass using machine translation would be great. Is going back to InDesign for this particular need the best choice? Are there any alternatives worth mentioning which Affinity fans like?
  4. It is built manually. I don’t know to what extent the automated TOC format could be tweaked this way. The tab characters might be a problem for the index generator. Tweaking the TOC paragraph styles to add tab stops should be straightforward as they are presumably just standard paragraph styles.
  5. I figured it out. The answer is tab stops. Starts on the 3rd page of the attached PDF. I have four new Paragraph styles. ETOC1, ETOC2, ETOC3, and ETOC3Centered. ETOC3 has two tab stops with the dot as the separator on one of them. This did the trick. There are also some character styles which are used to add color here and there, but those are ancillary to solution. The affinity publisher provided youtube video on tabs was very helpful. The initial index is still the standard one, so Bringhurst would still hate that one. ExerciseIndexTest2LeSSExecutiveWorkshopHandouts.pdf
  6. I tried uploading a photo of the example, but the site didn't seem to let me do it.
  7. I am manually creating a manual table of contents within Affinity Publisher. I am trying to follow the second example seen at the top of page 36 of The Elements of Typographic Style by Robert Bringhurst. (Fourth Edition, version 4.2) His example has a list of referenced names and the page numbers joined with a dot, with the line centered around the dot. It is not clear to me if I can do this with a paragraph style alone. Alternatively, I think it might be necessary to use a paragraph style in combination with two text styles. One character style for the left hand content, and one text style for the right hand content. I pretty much have to do this manually because Affinity Publisher still lacks proper page reference support for what I am trying to do. Elsewhere in the document I am using an auto-generated TOC with default character styles. I am avoiding changing those styles for now, even though Bringhurst would hate them. For your amusement here is a relevant quote from page 35 of Bringhurst: "Lists, such as contents pages and recipes, are opportunities to build architectural structures in which the space between the elements both separates and binds. The two favorite ways of destroying such an opportunity are setting great chasms of space that the eye cannot leap without help from the hand, and setting unenlightening rows of dots (dot leaders, they are called) that force the eye to walk the width of the page like a prisoner being escorted back to his cell." Trying not to be guilty of that!
  8. I like what @Wosven suggests with the caveat that any product company should strive to fully understand the ecosystem within which their offering is used. This includes maintaining awareness of significant scenarios and accounting for them during development. Ensuring the implementation is not locked to this or that printer makes perfect sense. I can see how the ability to import and export settings is a great idea. That said, Affinity is still the underdog and can’t assume printers will provide Affinity specific settings like they do for Adobe. This isn’t fair or ideal, but it is the current market reality. I don’t know this ecosystem, but I suspect there are only a few combinations of commercial digital printers and pre-press pipelines that are in common usage worth focusing on.
  9. I would suggest a fresh install should always include whichever RGB color profiles are preferred by LuLu, Amazon KDP, and other major print on demand book printers who prefer RGB. It would also be very nice if Affinity could write an article, FAQ entry, or other appropriate documentation regarding how to best produce an optimal file for these POD companies. Some of the links earlier in this thread provide the details on LuLu. Amazon KDP has similar guideline documents.
  10. When initially authoring content I am a big fan of writing in simple plain text, or some form of basic semantic markup. The two semantic markups that come to mind are Markdown and LaTex. This approach keeps down the cognitive clutter and is also very conducive to keeping the text under proper source control using tools such as Git, Subversion, or the like. It also lets people use most any plain text editor of their choice. Even the Scrivener type fans are effectively plain text people. Layout and graphic design on the other hand is best expressed visually. Performing page layout in something like Affinity Publisher, InDesign, etc. is a great improvement over writing TeX, LaTex, or groff macros or plugins. Unfortunately, I'm not aware of any visual page layout tool that can easily consume a simple semantic markup file for the text content (IDML doesn't count). There would need to be some simple user friendly way to extend to the semantic markup notation to map it to new paragraph or text styles above some pre-defined basic set. Lastly, some sort of collaborative editing support for the body text such as that seen in Google Docs would be exceptionally useful. The collaborative editing and commenting capability would only need to focus on the semantically marked up text. Presumably the visual layout design would have to remain a locking style model given the complexity of providing automated merge functionality on visual layout. Think of a marriage between something like Google Docs and a Git backed wiki with semantic markup text files. All of this would need to be designed from the perspective of the overall ecosystem, while ensuring as much flexibility in tooling choices as possible. The key bit of missing functionality is the ability of Affinity Publisher to consume simple semantic markup; yet any testing, tutorials, and documentation need to keep the bigger context in mind. This includes making sure there is support for a build system to easily kick off a command line run which will render a PDF or any other supported output format. To achieve meaningful market impact will likely require key functionality is open source. One shouldn't have to fight license problems when trying to get the solution to run on a continuous integration infrastructure. At the same time, interactive usage will probably need to require a license. The revenue challenge is to figure out how Affinity can be properly paid for its efforts while not destroying the usability and mass market affordability of the product offering.
  11. I should also mention I only have Affinity Publisher without any of the other Affinity applications. It is always possible the installers for one of the other Affinity applications installs a critical library the Affinity Publisher installer failed to install. This is the sort of thing that can easily get overlooked in testing.
  12. Try this on another M1 based Mac and you will likely be able to reproduce my issue.
  13. The same OSX build could in theory perform differently based on hardware. The application could easily look for this or that required library or OS feature and change behavior based on the result. The CPU change is pretty major and could easily result in various subtle differences. I would never be comfortable without both Intel and M1 macs running in a continuous integration test infrastructure if developing a desktop OSX application.
  14. And to be really certain any resulting PDF should be checked for transparencies. Better yet consider an upload to Lulu, Amazon KDP and other popular choices and see if they produce any pre-press check errors.
  15. As you can see only CMYK and Gray are available options for me with PDF/X-3:2003. My Macbook Pro: Mac OS Monterey Version 12.1, MacBook Pro (16-inch, 2021), Apple M1 Max, 64 GB Affinity Publisher Version: 1.10.4
  16. Here is a zipped directory I created by using "Save as Package". I presume this helps to make the document a bit more transportable. ExampleDocument.zip
  17. As to missing linked files, I have confirmed all my resources are embedded not linked.
  18. The RGB color space is not an available option to me with PDD/X-3:2003. I should mention I am running on a new MacBook Pro M1. Perhaps support varies by platform. The M1 has the new apple CPU not an Intel based CPU, so that may also be a factor. Please advise.
  19. Here are some of the export settings I tried. The one with the LuLu_T11 preset is what I eventually used for the proof copy I ordered after giving up on creating an RGB version.
  20. Here are PDFs of my relevant LuLu.com support tickets. 312486_What_color_profiles.pdf 314224_Please_Validate_Export_Settings.pdf
  21. Here is a subset of my course pack document. I have been careful to include each variation of content found in the full version. As you will see this document is a hodgepodge of the following: * Slide handout PDF created in PowerPoint. * Properly hand typeset text and images. * Various PDFs copied into the document. The typefaces are all over the place. The vast majority are available from Adobe Creative Cloud. I maintain a license of InCopy (cheapest possible choice) just to maintain access to the Adobe typefaces. I seemed to get transparency warnings all over the place. ExampleHandouts.afpub
  22. Here are the relevant Document Setup configurations and PDF Export configurations I ultimately ended up using to produce a CYMK PDF/X-1:2003 file for LuLu.com. I am yet to receive my proof book copy to fully validate the result.
×
×
  • 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.