Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by Lagarto

  1. If you depend on the fonts that cause conflicts, there might be point in getting a utlity like TransType 4 to resolve name conflicts. There are probably free tools available, too, but hardly ones that are as easy to use as TransType.
  2. My guess is that the cause for these problems is either of the superfamilies Helvetica Neue, or Frutiger (or some other where you have several substyles grouped under the same family), especially if you have mixed Adobe Type 1 (.PFB + .PFM pair) and TrueType/OpenType versions, since this is likely to cause name conflicts which may result in this kind of strange behavior. There is at least one post on Windows Publisher beta forum that is similar to this case. I would start by uninstalling all Type 1 fonts and seeing if that already helps. Then re-installing one-by-one other than fonts from superfamilies, and finally pinpoint the one that causes the error. Adobe apps arrange fonts more cleverly, and do not depend on Type 1 kind of meta data returned by system font enumeration that is often too generic (based on old 4-style family grouping), so that explains why you won't see this problem in InDesign etc.
  3. Exactly, I am just getting acquanited with Photo and I was looking for support for converting to indexed color modes (paletted images), which in Photoshop would allow this kind of effect simply by using local adaptive color reducton without dithering, like below, where the number of colors is reduced to 7: If more zone-like effect is wished, the number of colors could be still reduced, which would result in distorted and unbalanced effect, but then the palette colors could be manipulated directly to get the desired base colors.
  4. Just quick and dirty: you could try Selective Color > Blues > Set Cyan to 100 > Merge. Then reapply, select again Blues, and reduce Black to get the desired darkness. As demonstrated in the attached reduced Photoshop file that has the original and manipulation in layers. selectiveblues_original_fixed.psd
  5. The terminology can be confusing but I think it is understandable in the context of cross-editing capabilities, and common file format for all three apps. Affinity Publisher was, after all, the latest app in the trio. Photoshop also has layers that in a way behave like "objects" (e.g., you can align layers as if they were objects or a group of objects in a vector based app), and then it calls "objects" as "shapes". I am not sure if there can be any intrinsically correct terminology for graphic applications, especially as they are typically hybrid in these days. Perhaps Serif chooses to call InDesign kind of (global) "layers" in Affinity Publisher as "sheets" -- surely the term cannot be reserved to describe only objects in the physical world (like a sheet of paper), or objects in a spreadsheet app (which too, are kinds of "layers", as they can interact in a way similarly as graphic layers)? When PDFs are created in code, the term that is used for "layers" is often "creating or changing the content stream" as that describes accurately what is done when there is need to re-write/re-position on the same page data from a different stream that cannot be accessed meaningfully at the time the first stream was output. The decision to call them "layers" rather than "content streams" was no doubt more user-friendly, but it is not by any means accurate in terms of how they are created. EDIT. Oops, a very old topic. But still useful reading when learning to use these apps as they behave in many ways differently than Adobe apps.
  6. This way I realized that you can achieve a node editable container, no matter what its initial shape is. If this is tried the other way around, first placing text in standard rectangle shaped text frame, then converting it to curves, the contained text is contained to curves, as well!
  7. Thanks, very useful! This allows fully controllable and shapable containers.
  8. A very good question! I would have assumed that this is possible, similarly as InDesign, simply by editing the text frame nodes, but it does not appear to be so? It is however possible to use any shape (e.g. a triangle, or Trapezoid, to achieve the effect described in your post) as the container for the text, but I am not sure if it is possible to rehape this container by using node edit mode?
  9. Definitely by design! One often needs auxiliary objects to perform complex text wrapping and does not want these objects to be visible! InDesign applies text wrapping disregarding the visibility state of wrapping objects but allows an option where wrapping can be turned off layer-wise if the layer is hidden.
  10. Lagarto

    A random "glyph" problem?

    I do not think that there is anything wrong with Roboto. Not applying ligatures automatically is just fine. If you want to use them, you can enable them in apps that support OpenType features. The reason why you initially had the ff ligature in your text as a glyph, rather than as a feature that you had wished to use, was probably that the source application had replaced the mere attribute with a hard coded glyph. This does not work well if you need to transfer the text from one app to another. "Client" refers to leaving formatting decisions to the user and their preferred apps, rather than being dependable on a feature that the app, or individual font, is supposed to have. In this case this means that it is always better to just have "ff" (and other character pairs that can have ligature forms) as two single characters and use a software setting for applying ligatures, than trusting that a hard coded glyph will be correctly handled when any of the affecting parameters change (like changing of the font, or copying text via Clipboard to another app). Actually the source of the hard coded ligature could well be an Affinity created pdf, since ligatures are hard coded in them. Just compare the attached two pdf files and copy paste the text from them to a new Publisher document (or to any other document). You get two f characters from InDesign created pdf, also where discretionary ligature is used, but unrecognized glyph (a "box") from Affinity Publisher created pdf. roboto_ligatures_apub.pdf roboto_ligatures_id.pdf
  11. But isn't this a designed feature? If you want to move the text frame that is based on a master page, you are supposed to "detach edit" it (that is, right click on the master layer in the Layers tab and choose "Edit detached" from the context menu)? That is, the text frame is in that respect similar as any other object placed on the master page, but it just has that important exception that it accepts changing of the text content. EDIT: Dragging and dropping individual text elements like words etc. is possible also in a text frame based on a master page. But now that I re-read your description I am not sure if I understood what you actually meant. EDIT2: Ok, finally got it, just realized that drag and drop editing is only possibe when detach-editing is on while it probably should be possibe also without. Similar behavior applies also to inline graphics placed within the text, and I am not sure if graphics is supposed to be moveable, without detach editing. Possibly not, since even if the graphic object is floating, it cannot be moved, if it is an element in the master page layer. That might explain why drag-and-drop editing is disabled for text, as well. However the visual controls indicate that drag-and-drop would be available, while it is not.
  12. Lagarto

    A random "glyph" problem?

    If you want to correct this problem, simply just replace the dicretionary ligature that you have in your text (double ff) with two f characters. This way the double f's get rendered as standard ligature, or discretionary ones, or just two consecutive f characters, depending on the client app's settings and specified according to your preferences, and disregarding the font and any language settings.
  13. I tested this with (bible.txt), and it took about a minute to get all text flown and move to last page (and get that page item rendered in Page panel), But generation of the page previews for other pages took a few minutes, and the app was unresponsive most of the time (did not try much else than moving to another page: that could be done, but typically with a significant delay, e.g. about 30 to 60 seconds or so). But what is crucial is that Affinity Publisher more or less hogs all CPU time and available memory of the system. The peak CPU time used was around 90% during the operation, while it most of the time stayed somewhere around 50%, but it consumed total of 12GB of the availabe 16GB of memory. I compared that with InDesign, where the complete text was fully rendered and available for editing throughout the publication (as it there were only a couple of pages) in about a minute, where the peak CPU time used was around 12% and memory consumption around 290MB. QuarkXPress (2018) behaved much the same as InDesign with maximum of 10% CPU time though it took about 500MB of memory (probably partly because it created a few hundreds of pages more with its default styles and margins than ID). QXP also does not struggle at all when subsequently editing the text (e.g. adding text in the middle of the publication), even if there is a slight delay in processing of text (this, however, can be said of much of text operations in QXP especially in WIndows version -- but all in all, this is all good, just saying it, because there is a noticeable difference compared to ID). NOTE: After AP gets its job done (rendering the page previews, etc.), memory consumption gets about half of the peak, around 6GB, but whatever is done in the app to modify the text or the layout (e.g., adding even just a character, adding a picture, etc.) is very sluggish, and stays so. The size of the saved file is also very big (212MB), compared to about 16MB of .INDD and 11.5MB of .QXP. While the exceptionally long autoflow time seems like a bug (or is it just a symptom of getting out of RAM and needing to virtualize on the disk?) (as I have repeated this several times and the text gets flown within a minute), I have tried laying out long documents with Affinity Publisher as many times that I can say that sluggishness and resource hogging in editing (after having all text in) seems to be a feature rather than a bug, and probably related to the file format, which simply just does not work well with long documents, at least at this stage of development. The limit of "long" being somewhere around 100 pages. It stays still manageable with a couple of hundred of pages even when containing lots of images but complexitity of layout being more in book than magazine category.
  14. My experience is the same with any longer document (one consisting of several hundreds of pages), even with mere text. The experience may be further deteriorated with a mutliple monitor system and a graphic driver that does not support acceleration. I would just split the long document in parts (you can start page numbering at specific number, but would need to do certain jobs multiple times, of course, for each separate section of the book). If you need to have one pdf, then you'd need do use a tool like Debenu PDF Tools (free) to combine multiple pdfs, or purchase a professional PDF editor for more complex tasks.
  15. For me the least painful way to add global colors is to first create a rectangle for each main color that I need in the document, e.g. five rectangles for five colors. Then I open the Swatches panel and create the document palette. Then I seleect first of the rectangles. if I need spot colors, I activate one of the Pantone color libraries, and assign the selected rectangle a PMS color value. If I need CMYK color swatches, etc., I detach the Color panel, activate the slider controls and choose the desired color value. Then I select the next rectangle and repeat the process, and so on, until i have all main document colors defined. After this I activate the document palette from the Swatches panel, select the rectangles one by one, and click "Add fill to palette". This way I get color definitions as swatch names. Then I right click each swatch in the document palette that I want to make globar, and select "Make Global" from the context menu. This way I can avoid most of the back and forth hassle, and can also have meaningful swatch names. EDIT: If you instead prefer the global colors to have your own custom swatch names, you'd naturally click the right plus button to have a generic name and made it immediately global. Then editing can be simply achieved by double clicking the swatch in the document palette. But if you have the global swatches with color values, this is not a good idea as you cannot have the color names updated to match the new definition. It is a better idea to just create a new global swatch rather than seeing the trouble of renaming the swatch.
  16. A couple of further notes: 1) I can now confirm that missing of the second but last character in the "Hellanóre" test string in Adobe apps, is indeed a glitch in CS6 version apps. In current CC versions the charcter renders fine. 2) I can now confirm that CorelDRAW (2017 version) also perfectly renders NotoTeng on the screen, and in the pdf it produces (there is still Tengwar Parmo included in the same file, as a reference). 3) PDF produced by OTM attached in the previous post is useless in the sense that it has vectorized text, but the font (NotoTeng) operates correctly both in OTM 7.9 and FontLab VI. These three things seem to further confirm that there is something wrong in the way Affinity Publisher exports OpenType text that uses these kinds of features. otfeatures_corel.pdf UPDATE: Further note on point 1 above: InDesign (CC 14.0) renders that second but last character and now renders the text perfectly both on screen and pdf, while Illustrator (CC 23.0) still loses the second but last character, and does not support mark positioning, nor does Photoshop. The other apps belonging to the CC render the text in varying ways, e.g. they might render the text during the input, but once editing mode is finished, all mark positioning is lost, as demonstrated below in screemshot from Adobe XD. noto_teng_id_cc14.pdf
  17. I am not sure if I am talking about the same problem as the OP: 1) Create an object and assign it a pre-defined color values from the Colors palette, like HSL 339,90,50, then right click the swatch and choose "Edit Fill". 2) Change the color value whatever you wish, using whatever color model or color definition control, but the color value of the swatch does not change, nor does the color of the selected object, nor will there be the defined color swatch added to the document palette: So whatever is done here is useless, and for a good reason: why should anyone want to or be allowed to "edit" a library swatch? It is perfecly fine to allow editing just a color value of an object, or allow changing a color value of a swatch that existis in the document palette, but editing a library color just does not make sense. I don't know if this is a result of a combination of having latest beta versions of all three apps installed on the same system, as Publisher lags behind at the moment from Photo and Designer, but as said, color palettes have been (IMO) a mess in Affinity apps right from the beginning, so personally I see any change in the feature as a sign that there are some intentions to improve the thing...
  18. No wasting time at all, this was a useful demonstration of problems one is likely to experience when having name conflicts with installed fonts. The font files themselves can be well crafted and from good sources but an unfortunate combination of family names can cause strange problems, like the one you described. So instead of trying to find the actual cause for the problem (why quotation marks are replaced by another glyph), it is often useful to just trying to eliminate possible conflicting parts. These kinds of problems are typical when there are older Type 1 fonts and their TrueType/OpenType converted updated versions (or, TTF TrueTypes and their updated .OTF TrueType versions) installed on the same system. Adobe e.g. renamed their OpenType versions so that they do not conflict with earlier Type 1 versions but sometimes conversions have been done more or less mechanically so that name conflcts arise.
  19. It works fine on InDesign and PDF exports it creates, it works fine in OTM, its text viewer, and on a print it creates. It renders fine on Affinity Publisher, screen but cannot be exported correctly, and does not print correctly neither with Adobe Acrobat driver (Distiller 10.1.16), nor with PDF X-Change, generated from Affinity Publisher. So we are back in square one, a genuine Affinity Publisher related PDF Export and print problem, which is not just a PDFLib issue. I think these tests exclude variables related to possible problems with the font. UPDATE: It does NOT work ok on InDesign, it has the same problem as before, the second but last character (related to localized forms) is missing, but what is shown on the screen is also exported to pdf. But as it behaves now correctly in OTM, it is possible that this is somehow InDesign related, and might be a glitch in CS6, and fixed in later versions. noto_teng_otm_via_adobe.pdf noto_teng_id.pdf noto_teng_ap_via_xchange.pdf noto_teng_ap_via_adobe.pdf noto_teng_ap.pdf
  20. I tried this with Bitstream OpenType (TrueType) versions that come with CorelDRAW but did not experience any problems. Do yoou have the same source for these fonts? I exported using the default (print) option. zapf_humanist_afpub.pdf
  21. Here's a screenshot from OTM full version that can display text samples while turning on and off OT features: The output is more or less the same as that on Pages on macOS. Note that when viewing GPOS and GSUB tables, there are no problems when showing these features (mark positioning and localized forms) so it seems there is nothing wrong with anchor pair definitions themselves. But in the text view, only l'ocl' has effect, and 'mark' (turning off of which places the underbar in its non-positioned location), but 'mkmk' does not have any effect, and stylistic set 01 ('ss01') turned on hides the three dot vocal marker. Changing the script and/or language does not have any effect on rendering. It remains a mystery why Affinity apps and FontForge can render the text on screen, while Adobe apps and font tools like OTM cannot. I hope you manage to solve the problem so that you get the font correctly rendered anywhere, and also in PDFs.
  22. I am experiencing the same but cannot recall how exactly it used to behave -- badly, anyway, so I hope this is a sign that this feature is now under development. Anyway: the library colors should not be editable so the Edit menu command should be disabled whenever a library swatch is selected. Then it would be nice if any library swatch selected would be automatically added to the document palette (which would be created automatically if not already existing), or that document palette would be made as a separate control for easier handling, and that when a swatch on a document palette is edited, its color values could be updated by command as the new color name (or made an automatically updatable name, if desired), tints and shades based on 100% color value would retain their parenthood, etc., etc. It is a long list but it seems there is little point in commenting a feature that does not yet operate as planned (I hope there are plans, anyway)..
  23. The proper PDF file can be created also when using Adobe Acrobat printer driver (basically Acrobat Distiller, in this case v. 10.1.16). I used press settings and ensured that document fonts are included. But similarly as with PDF X-Change, the original Tengwar cannot be exported correctly, even if it shows correctly in Affinity Publisher. This would be a very interesting thing to examine closer, and possibly resolve, but I am not sure if it is an Affinity related problem, but rather a font related problem that touches multiple applications and multiple pdf libraries. But if this turns out to be something that Affinity apps can do (while other apps in this business fail to do), then it is probably a thing many Affinity users want to know. adieresis_posmark_ap_via_adobe.pdf
  24. InDesign's PDF Export just tends to work right (never failed me, at least). There has not been inconsistency with what is shown by InDesign on the screen, and what gets output in the PDF. So when it cannot render the Tengwar text on the screen, the text looks equally wrong in the PDF. With Affinity Publisher it is different because it uses PDFLib. I could not get Adobe Acrobat printer driver render the adieresis text from Affinity Publisher right (I did not try with all possible settings, though, and certain settings might work), but surprisinly PDF X-Change could do it.
  25. ...and interestingly, if I create a PDF by printing from Affinity Publisher to PDF-XChange driver, it renders correctly. So not an Affinity issue but a PDFLib issue? Yet the original example with Tenwar Parmo exports incorrectly even if printed to PDF-XChange driver. adieresis_posmark_ap_viapdfxchange.pdf tengwar_apviapdfxchange.pdf

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.