Jump to content

Lagarto

Members
  • Content count

    349
  • Joined

  • Last visited

Everything posted by Lagarto

  1. This is how the input looks in InDesign (CS6). The text input requires "Mark Positioning" and "Localized Forms" OpenType features checked, to display the combined forms. But they do not align properly, as they seem to do in Affinity Publisher. QuarkXPress 2018 does not list these OpenType features and I cannot input this there. Have you any tool where you can test whether the font actually behaves correctly? i opened this in FontLab VI (6.1.4.7044) but when I compile the features set get an error on line 288 in mkmk table, "markClass y <anchor 0 -128> @;", the output window saying that "@" is invalid token. My knowledge of OpenType is very elementary so I have no clue where to go from there but the compile error seems to prohibit me from testing the feature set in FontLab Preview panel or Text window, and showing or even listing any of the supported features like lcl, mark and mkmk tables there. Since Affinity Publisher renders the input correctly, and can convert it to curves properly, there is of course a chance that this just gets rendered badly in the PDF viewer, but I have tested many, and it does not seem so.
  2. Yes, I noticed this, too, and at first thought that turning on/off the baseline within the text frame was confused (so that the gap beyond the wrap amount could have been explained by snapping to the baseline). But this is actually a third way to avoid the wrap anomaly, and specify the distance of the text from the top of the frame (i.e., turning on text frame specific baseline and specify the line spacing a bit bigger than the point size, and making sure the paragraph attrobute for baseline grid is turned on)..
  3. True, this is a strange feature (or a bug?), or then there is some snapping going on without an obvious setting (I at least ensured that there is no baseline snapping, nor baseline grid turned on) Another workaround would be removing the text wrap from the image, and add 1 mm inset at the top of the caption text frame.
  4. Conversely, it seems we neither can ADD meaningfully arrowhead(s) in a text frame, yet the controls for arrow heads are available when an outline (stroke width) is specified for a text frame. The arrowhead Start and End boxes also seem to behave exactly the same (in an uncontrolled manner) as in a situation where they were initially created as text frame features as a result of conversion. Also, if the text frame is converted to curves, and ungrouped, and the outline is broken apart, the arrowheads do not seem to appear... Is there actually a situation where arrowheads could be applied to a text frame?
  5. Wow, I educated myself a bit in Tengwar, and can now see that Affinity Publisher is the only one of these three page layout apps that actually renders the font correctly! The way I composed these in InDesign and Quark was, as mentioned, manual glyph composition by using negative kerning and shift, which is of course all wrong!
  6. Ok, thanks. Interesting font this is, and a good test case for support of opentype specific features.
  7. Yes, true, it somehow messes this up when exporting. I wonder how these chracters are different if you compare them with simple diacritics like åäö, which also include vertical shift?
  8. I think we are supposed to be able to type any character in the optical alignment box, but it just does not accept other than standard characters... The same problem seems to be in QuarkXPress (2018), when trying to enter this punctuation character in the list of trailing hanging punctuation characters. Only InDesign does this right, it probably reads correctly this as a punctuation character period.alt based on classification.
  9. Quite interesting. I reproduced this in InDesign and QuarkXPress and it seems to work there (see attached files). But are you supposed to type these characters from the keyboard, and use ligatures and diacritics, as the way I produced these characters was just using negative kerning and character shift with single glyphs, which is a bit hard way to write in Elven tongues (though I am not sure if there is even supposed to be an easy way...) Additionally, In Affinity Publisher, the Glyphs panel does not show the currently selected character, which makes it a bit awkward to use these kinds of custom fonts in this app. With regular fonts character shift and negative kerning seems to work fine in Publisher, but not with this font for some reason. fontproblem_quark.pdf fontproblem_id.pdf fontproblem_apub2.pdf
  10. An update worth noting if you're using Notepad++ (v 7.7.0 or 7.7.1 ). The currrent version of the NppExport plug-in (0.2.8) that is supposed to be copy syntax highlighting in RTF (and HTML format) does not include coloring, but an updated version (not yet automatically managed by Notepad++) 0.2.9 does (as do earlier versions of Notepad ++ with earlier plug-in versions): https://github.com/chcg/NPP_ExportPlugin/releases/tag/0.2.9.21 This is probably the most versatile tool for transferring customizable code highlighting of any of the many supported languages (or ones for which you have added support yourself) from a source file to Affinity Publisher.
  11. I think the situation is pretty much identical, Xcode is free (as is Visual Studio on Windows platform). But it of course depends on which language you use and whether syntax highlighting is supported in that language in those IDEs. On both platforms you have Visual Studio Code, which allows copying syntax highlighting using HTML, but you typically need an intermedialy app like Word, Pages, or LibreOffice to transfer the code in RTF to InDesign or Affinity Publisher.
  12. I replied on that forum, but repeat the same information here, too: on macOS, you can use Xcode to copy paste syntax colored code directly from the editor to Affinity Publisher. That is, Xcode does support RTF formatting when it copies the code onto the Clipboard. HTML and Markdown support, in due time, would of course be a nice addition!
  13. This depends on whether the code editor supports RTF format when copying code onto the Clipboard. If it does, the syntax coloring will be pasted in Affinity Publisher. I just tested this with Xcode 10, and it works just fine. On Windows platform Visual Studio supports RTF format with Clipboard, as does Delphi XE (via a free plug-in, from XE3 up to XE10.1). Many code editors (like Visual Studio Code) might support only HMTL or Markdown, and it would be nice of course to have direct support for these formats, as well.
  14. Which plug-in? There is one that is free and supports both HTML and RTF formatting (available for all Delphi versions starting from 3 and up to 10.1): https://www.tmssoftware.com/site/tmsiderichclip.asp I have pretty old Delphi (XE7), but it works just fine, and you can copy syntax highlighted code directly from Delphi to Affinity Publisher or InDesign:
  15. Good to know. And I'd suppose it does, as I do not think that it matters which application is the source for the RTF formatted data placed on the Clipboard(?).
  16. It much depends. I use mostly Visual Studio and copy pasting using the Clipboard from there to InDesign and Affinity Publisher works really well, as the formatting comes as RTF: Visual Studio Code seems to use HTML when copying the code to Clipboard, so that would not result in syntax coloring be retained, neither in InDesign (CS6), nor in Affinity Publisher, but if the receiving app supports HTML, like Word, pasting first there, and copying again (as RTF) would allow you to paste syntax coloring also in InDesign or Affinity Publisher. As for other code editors, e.g. Notepad++, which supports syntax coloring for many languages, I have not managed to copy paste information including syntax coloring to neither InDesign or Affinity Publisher. The same applies to Brackets. QuarkXPress (2018) does not seem to support pasting of colored RTF, at all. So if there is no plugin in the code-editor that supports RTF when copying syntax colored code to the Clipboard, I guess there is not an easy way to get colored code in page layout apps. HTML would work if you use Word (or Pages) as an intermediary tool. EDIT: Using LibreOffice seems to work equally well as an intermediary editor. I do not have currently XCode installed on my mac so I could not test this but if XCode is not an overkill for the job, I'd suppose it supports RTF when exchanging data via Clipboard.
  17. What is strange is that you seem to have received different kinds of error message related to the same problem (inability to save an already saved file), at least one related to user privileges, and one related to internal error. One thing that could poterntially have effect on an application's ability to save files that it has opened is having a background task that e.g. creates backup copies of documents, or an antivirus application that controls access of apps to certain locations on the system. For that purpose there might be point in saving in a location on your D drive that such apps are not watching for their operations. .If you typically save to a custom location on your D drive, does the problem also appear if you save somewhere along your "My documents" folder path? Do you have "My documents" (the system default folder for user documents) still on you C drive, or have you moved its location to the D drive?
  18. Do you mean reference point according to which objects are aligned to? I would like to see Affinity apps to have simiar thing as InDesign or Illustrator, where the Control key (or Alt key, in Illustrator) lets you pick the object (amongst selected objects) that is used as a reference point when aligning objects. In Affinity Publisher you can achieve something like this by selecting "First selected" or "Last selected" as an alignment option. But other than that, I have not noticed problems with being able to center align objects (in relation to center point of selection, page/spread edges, or margins).
  19. Ok, thanks. The thing is that the table auto-adjusment problem applies to both beta and the release version, and the most active users (or testers, to use the proper term) are likely to run the most recent beta. Reporting to one forum (the most recent one) should ideally have some kind of feedback from the developers, without a need to copy the post to parallel forums, or without a need to test whether a specific issue can be reproduced also when using the release version, and/or a macOs version. But I guess this is a matter of limited resources, and the focus is at this point somewhere else But if the code base is common, I can be pretty confident that the problems posted to this forum have been experienced also with release (and macOS) versions, and have accordinbly been properly acknowledged.. EDIT: Ok, thanks: corss posting...
  20. The serialization issues are actually one of my main worries with Affinity apps. Serif has shown great promise feature-wise, but the bread-and-butter things seem to need some serious attention. Personally I am not too enthusiastic about the concept of across-editing capabilities and common file format, as easy exchange of data has not been much of a worry when using Adobe apps. Editing is never far away, and e.g. most of the Illustrator objects can be copied across to InDesign using the Clipboard, etc. But file corruption is a serious problem, and securing that you do not easily lose your job is one thing that Adobe has done right, starting from CS v.1 (those who are old enough to remember what it used to be like with PageMaker know what I am talking about). So that's why I have been curious to know what could be the reason for the problems you have experienced. I have not experienced any i/o related problems with Affinity apps myself, and I have not seen many posts that report these kinds of problems, but there are posts that report problems with unexpectedly big file sizes, linking/embedding and especially importing files from cloud resources, problems related to across editing, etc., so this is one of the issues that I am following very closely. I'd appreciate if you could have patience and continue troubleshooting these issues for a while, as I think this could help us all to have a true alternative in this business!
  21. I wonder if we are reporting to an unread forum? Nobobdy at Serif seems to read the beta forum (at least on Windows side), even if there is a new beta... the post for the beta release had a request to post bug reports found in this release to a beta Mac forum, but I thought this was just an omission. But I have posted a beta-only specific bug related to text wrapping but no one has acknowledged it even this is a definite bug. I guess there is something more urgent at hand... Same with the topic post which is an 100% reproducile bug. Maybe it has already been reported on the Mac forum. The key customers...
  22. I don't mind that being possible but it should ideally be indicated somehow. It has always been a kind of a nuisance in InDesign that you need to change to page edge alignment when you have a grouped or single object selected as that is basically an obvious choice.
  23. I think that what it actually does (after you have pressed Ctrl+G to group), it first cancels that alignments performed, then groups the objects, but when you subsequently close the flyout just clicking outside of the flyout (without clciking Cancel or Ok), it actually applies the default vertical aignment option, which could be aligning to top of the page edge, or bottom, depending what has been done last, and now that you have a group, silently applies alignment in relation to page edges. In many ways, this is an odd mix of modal and non-modal controls. In a non-modal control you should not need to use Ok/Apply button if the alignment controls already perform an action, and cancel should be done by going back with the Undo history. In a modal control, all transformations with actual objects should be previews, which should automatically be canceled, if the user does not actually "Apply" the changes. Simply going away should not be allowed as some kind of an indeterminate "Ok", as it is now, and if it is, then the flyout should either be "pre-emptive" and disallow conflicting shortcuts (like grouping), OR, be aware and acknowledge that the user can e.g. group the objects in the middle of the alignment operation. We do not need Apple to know that
  24. This is continuing an off topic discussion but I could not resist on commenting this. I think the usefulness of paragraph composing depends much on the language, and also efficacy of the hyphenation algorithm. French has long words, but it also has articles, prepositions and short words to allow some room for alternative compositions. My mother tongue, Finnish is quite hopeless with long compound words and no articles and prepositions, so there is really no going back and use single line composer. That said, it is always a great pain to need to edit the text (e.g., change hyphenation), as that often means recomposition of the whole paragraph. Basically I use single-line compose only with jobs where I know beforehand that there will be much editing once the basicl layout is accomplished. But mediocre hyphenation algorithm combined with absence of paragraph composer makes use of Affinity Publisher a hard choice for narrow-column long-text book jobs in Finnish language. EDIT: Forgot to add that you are in an exceptional position with Bible publshing that you're not likely to get edits in the text that is once already carefully typeset so it is really a no brainer choice to use the paragraph composer :-)
  25. It is of course also partly a question of where you come: InDesign users are accustomed to using alignment panel that operates without needing to click Ok to apply alignments, and each click in the alignment button is recorded in the Undo history. I think this is more intuitive. It would be another thing if alignments really were just previews, and would not be applied unless Ok button is clickd or Enter is really pressed.
×

Important Information

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.