Jump to content

Lagarto

Members
  • Content count

    220
  • Joined

  • Last visited

About Lagarto

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Does not really seem the problem could be related to "non-ascii" characters in file names (and at least in the installation path), but one never knows (e.g., InDesign may still fail to recognize an image file as a valid TIFF file if its file name contains a non-ascii character), so it was worth a try. Just curiois: do you make much cross editing within Affinity apps, or have you experienced these problems also when you have edited the file with just Publisher?
  2. I noticed the following in the flix list of latest Designer and Photo beta (the equivalent beta has not been released for Publisher, yet): "Fixed crash when install location contains a non-ASCII character" Do you happen to have installed Publisher in custom location (I think that older Windows OS versions might also have localized standard paths)?
  3. Still related to the same feature: the opacity setting that is saved as part of the color definition, is reflected in the color swatch when they are viewed as a list, but not, if they are viewed as boxes. The opacity percentage is however shown also with boxes when you hover mouse pointer over the box. Note that the transparency is rendered similarly in these two view modes disregarding the UI bakground color (Dark or Light).
  4. Note that circle in the example is encoded as... style="opacity:0.5;vector-effect:none;fill:#333333;fill-opacity:1;stroke:none;stroke-width:0.5;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" ...so it has both fill and outline specific definition (set to 1 here), and a generic definition for just ¨opacity', and this is correcly interpreted for graphic objects but not for text.
  5. Related to this: transparency should ideally be handled as a separate feature from colors, even if it naturally affects the color. But the colors that are produced because of interaction of colored objects with transparencies against different backgrounds cannot be visualized meaningfully with a color. E.g., now if an object has 50% opacity defined, and the user clicks another color well in the Colors palette, the transparency changes back to 100%, which is not what is normally wanted. The transparency is the desired effect in its own right no matter what is the object color involved in the effect. It might need to be adjusted because of change of color, but ithe object's transparency setting should nevertheless stay the same even if its color is changed. Transparency effect still misses the percentage box in certain places, at least in the context of Text Frame panel, and it would be more important to have the editable box than a slider and a well which tries to visualize the effect. EDIT: Just remembered that Affinity apps handle object transparency also via layer (which is in practice an object property), and separately via Fill effect and Outline effect, so there is a way to apply a global transparency for the object, which is retained when its color is changed. Opacity is just an additional property of a color in Affinity apps. It may get confusing, but it may be handy to have opacity defined as a swatch property. In this perspective, the transparency should probably be somehow visualized. But ideally consistently so that the definition looks identical in all panels.
  6. Personally I do not think that it is so important to visualize the effect ot transparency in a color well, but if it is done, I think it should be done consistently in the Gradient panel, and the Color panel. Now if the user has dark UI, the transparency is shown against dark gray background in the Gradients panel, and against the light gray in the Colors panel. My preference would be having the transparency/opacity shown simply as a percentage value whereever it is defined, and show the actual effect against the background only in the object. Tints and shades, however, should be reflected in the color well (but not in the swatch, unless a new swatch is created based on tint/shade).
  7. The insertion point is indeed in the correct place (which can be noticed if you just click Find and subsequently type in a character), but it is displayed as if it were at the end of the line (and before the break symbol). One might expect to see it blinking in the beginning of the line (?).
  8. Did I undestand correctly that you have experienced this error with very small files, as well (e.g., with newly created files where you have placed the kinds of single eps or ai files that you had attached in your post)? I can imagine that complex files may cause different kinds of problems, but if you have constantly experienced corruption problems also with small, newly created files, and you have run disk diagnostics on your drive, then there might be something wrong with the installation or Affinity-related registry entries, so uninstall/reinstall might help.
  9. Interestingly, when the SVG file (svg_transparencies_from_ai.svg) attached above is opened in Affinity Publisher, and the transparency values have been reapplied manually, and the document is then exported as svg (with default "Export" options), the file opens correctly in Affinity Publisher, and renders also correctly e.g. in Chrome, but Illustrator messes up the transparencies! So it seems to be pretty much a matter of encoding, and ability to support different encoding methods. Affinity produced svg (attached) opened in Illustrator (CS6): ...and in Affinity Publisher: svg_transparencies_from_apub.svg
  10. The same happens when opening SVG 1.1 format files produced by Illustrator. The text imports as text (if the font used is installed on the system), but as opaque. The source has the opacity value correctly applied, and when opening this in Illustrator, the text is transparent. svg_transparencies_from_ai.svg svg_transparencies.ai
  11. Thanks for the explanations. Did I understand correctly that the safe method to encode ligatures is using the "concatenation" method, e.g. (U+0066+0069) for the ligature "fi", and (U+0074+0069) for the ligature "ti", rather than referring the existing code point for the glyph itself, "fi" (FB01), or "ti" (whereever that is placed in the font, whether subsetted or not)? Anyway, it was good to see that PDF-XChange (Editor Plus) can actually edit the text as if in text editor no matter how the ligatures are encoded, that is I can copy paste the actual Affinity Publisher created "ti" ligatures without problems, while I cannot do this in Adobe Acrobat (or any other tool, as when the PDF is opened, the "ti" won't be rendered, even in Affinity Publisher, and copy pasting from one app to another is guaranteed to fail when custom encoding is used). I had to purchase this tool recently because InDesign could not produce an acceptable PDF/A archive format for a thesis (!). I have now used the tool to automatically generate hierarchical bookmarks from a TOC (quite useful with Affinity Publisher), so it has proven to be quite a capable PDF tool!
  12. Actually it could also be so that Affinity Publisher specifically uses the actual ligature codepoints, while InDesign uses ligature attributes, and just "ti" and "tt" as single characters. So whether a ligature is shown or not, depends on the viewer (i.e., if hardcoded glyph, all viewers can show it, if an attribute, the viewer must support the ligature as a feature), and whether a ligature codepoint is used as a glyph or not, when copy pasted, depends on the destination software (i.e., whether the destination software decomposes the hardcoded glyph as separate characters, or supports use of hardcoded ligature glyph itself not as an attribute but glyph). See below how PDF-XChange can edit and copy the selected ligature in the PDF created with Affinity Publisher ("ti" as a hard-coded glyph), which PDF-XChange can copy paste to duplicate it: ...and below editing the PDF created by InDesign, where "t" and "i" are separate glyphs which are rendered as ligature glyph "ti" because it has been coded as formatting attribute: Just guessing. I do not know internals of PDF encoding, but this kind of makes sense. EDIT: More guessing... The "attribute" status seems to be achieved by encoding the composing character codes to follow each other, e.g. "t" + "i", which the rendering application maps to the actual ligature glyph, if it supports the feature, and the font has the corresponding iigature glyph; and as separate glyphs "t" and "i", if it there is no support. Affinity Publisher seems to refer directly the ligature glyph code, so that when it is copy pasted it does not necessarily get correctly rendered in the destination app. See below ligatures_apub2.pdf, which has ligature "fi" added in the text. When this text is copy pasted back to Affinity Publisher (or Illustrator, or InDesign, etc), the "fi" ligature will be correctly rendered (either as ligature "fi" or separate "f" and "i", depdending on whether standard ligature atttibute is turned on in the destination app), but not "ti" (which is not supported in most fonts, but will not be rendered even if Calibri font, that supports it, is retained in the destination app). Don't know whether it is a question of these two ligatures having been encoded differently, or whether both are "hard coded" (referring directly the ligature glyphs), and only "fi" gets mapped to ligature "attribute" by encoding it as "f" + "i" (U+0066+0069). Anyway, concatenating the composing characters seems to be the safer method, as it is not dependent on the font's capabilities, or the rendeing application's ability to use ligature glyphs.. ligatures_apub2.pdf
  13. Here's one created in InDesign and Affinity Publisher. I think it is as MikeW mentioned above, Affinity does not use the font's codepoint for the ligature but just uses an unused Unicode codepoint, which shows when you copy paste the text. If you copy paste the text from PDF created by InDesign, you get those characters decomposed (so that the destination software defines whether a ligure is used or not). ligatures_id.pdf ligatures_apub.pdf
  14. There is no surprise, as far as I know variable fonts are not supported in InDesign or QuarkXPress, either, at this stage (even if Illustrator and Photoshop support them).
  15. I think that there is a bug when a master page object's outline has center stroke alignment, and it is placed outside the page area. The outer part of the line width will not be drawn on pages where the master is applied (even if such objects are drawn correctly when copied directly onto the page).. I changed the master page object's stroke alignment option to "inside", and placed the rectangle at -3 mm, -3 mm, 426 mm wide and 303 mm high, and then it seems to be correctly drawn on pages where the master is applied. I also changed the width of the rectangle outline to 3mm (instead of 8pt). (Note that the document bleed was set at 3mm for all edges, not 5mm.) Affinity A3 template with 3mm Bleed.afpub
×