Jump to content

Lagarto

Members
  • Content count

    623
  • Joined

  • Last visited

Posts posted by Lagarto


  1. 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". 

    edit_library_swatch1.jpg.3361e348437ae040ead65ef429a89ac4.jpg

    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:

    edit_library_swatch2.jpg.2ace94674114b6756af5310935fb4c33.jpg

    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...

     


  2. 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.


  3. 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


  4. Here's a screenshot from OTM full version that can display text samples while turning on and off OT features:

    tengwar_otmfull.thumb.jpg.72d6a0af04041c13d8814c406c5460bd.jpg 

    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.  


  5. 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).. 


  6. 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


  7. 1 hour ago, Evgenii said:

    Then why InDesign's export works right, and Publisher's doesn't?

    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.


  8. I downloaded the trial (or Light) version of OTM and there are no problems displaying correctly the mark positionings:

     

    tengwar_otm.jpg.a2c808d2173a83e9bc6cc385665f2be9.jpg

    I do not know if this tool has an option to input text and try how combinations of glyphs using mark positioning and local forms behave, as the problem does seem to be rather in input than the table data.

    The Light version allows you to export OT tables which might be useful when comparing with feature tables created in FontForge. I'll try if importing OTM exported feature tables in FontLab Studio makes any difference there.

     


  9. Sorry, missed it there. This is getting really interesting, as I thought the problem was that FontForge can show this with the actual source code of the font, while it can handle this directly when just opening the font! So it is definitely not a question of needing to reverse engineer anything...

    Please find attached the features exported when I open the font in FontLab Studio. The compile fails at line 314 in this combined export list, at the first marktomark  

    markClass y <anchor 0 -128> @;

    ...because FontLab fails to put anything after the at sign (that is anchor the glyph class to anything).

    Was I supposed to completely replace the current feature set with the ones you attached above? I tried both by first erasing all features, then importing, or just importing and allowing FontLab to replace existing (equivalent tables, I suppose, leaving untouched any of the other tables), but both times just get a bunch of error messages, like this:

    "@DOWNTEHTA_DOWNTEHTA_LOOKUP" would be a 16th. <Font> No more than 15 different class names can be used with the "lookupflag MarkAttachmentType <class name." statement "@ALDA_DOWNTEHTA_LOOKUP" would be a 16th. 

    -- --

    <Font> aborting because of errors

    I wonder if I'd need to import the classes first to get this working.

    Anyway, perhaps you can make something of the exported features list. It appears as if FontLab simply just fails to read the font information, expecting the feature tables to be encoded differently.

    I just used up my trial periods with Robofont and Glyphs but I'll try to install them on another computer to see how they open and handle this font. Quite useful learning process and introduction to internals of OpenType for me, but I'm genuinely interested to see why so different renderings in different apps, and on top of that, different PDF renderings. 

     

    tengparm-regular.fea


  10. Ok, thanks. The parallel behavior can be seen when aligining a bottom-aligned text frame on top of an object that wraps around (but not if the text frame is top-aligned). A bit odd behavior but probably related to guaranteeing lee-way for handling text related formatting within the leading, disregarding the actual measurements. Not a problem because the same effect can easily be achieved with other methods.


  11. It is hard to find apps that support position marks and localized forms. Pages seems to do that, but it also renders this differently from Affinity Publisher, and also differently from InDesign:

    hellanore_pages.png.78b6a3d61e65ba2ddbc58ec846ca5151.png

    It is interesting that Adobe apps behave differently from Pages, which renders the second but last character similarly as Publisher (but which is omitted completely in Adobe apps).

    The way the forms are combined in this font is very interesting, and it is a clever way to input a complex script and foreign tongue phonetically. E,g, the way the second character is composed, getting a three key input, is peculiar and fun (at least in Western perspective). But I wonder whether there is some rule as for validating how successive keys can be grouped, and how the separateness of key input is resolved? The fact that these three apps, Affinity Publisher, Adobe InDesign and Pages each render the font differently, and the fact that the PDF produced from the Affinity rendered text is also shown differently, suggests that there is some irregularity in the way these tables are encoded in this font.

    (The fact that the font does not compile in FontLab Studio, and that the FontLab documentation gives different syntax for encoding e.g. the MKMK table and anchor pairs, than shown when operning the .TTF file, suggests that there can be multiple ways to encode this information; or perhaps it is just a question of FontLab's attempt to read (de-engineer) the information included in the font, and problems resulted from inadequacies in this process.)

    Note from the attached pdf that if I create a PDF print output (using Adobe Acrobat Printer) from the text created in Affinity Publisher, it is also rendered differently from the PDF created by using Affinity Export. This is pretty close to the way Pages renders the text, except for the first character. 

    I suppose these features (LOCL, MARK, MKMK) are used typically in Asian scripts (kanjis etc.) so they are definitely in good use, so it is unlikely that the feature set would not be well supported at least in Adobe apps. But it would be very interesting to know the reason for these differences.

    Is it possible to type in "Hellanóre" in FontForger in some preview window and see that the text renders correctly there? Or is Affinity Publisher the only app where you have tested the functionality of the input?

    tengwar_apub_printadobe.pdf


  12. Sorry for my ignorance, but I'm not sure if InDesign (at least CS6) allows to define the typography script (?). In Affinity Publisher this can be done (along with typography language), but it does not seem to have any difference whether Latin, Auto or Default is used (for this particular font), not also when the pdf is exported.

    But if you managed to produce different behavior with the test font you mentioned, it is worh testing if such definitions would resolve the problem with Tengwar font, as well. I can help you with testing if there is any need. Btw, when opening the Tengwar font in FontLab, the font cannot be identified (filtered out) with any writing system (other than "Any"), so the font's writing system is not identified with "Latin". Don't know if it is even supposed to be, but I was just wondering whether there needs to be a match with "Latin" in GPOS, and the writing system of the whole font.


  13. 2 hours ago, Evgenii said:

    I only tested the font in FontForge and Publisher.

    Ok, thanks for all the information. I need to get familiar with FontForge, I just fiddle a bit with fonts (though I have lately become interested in combining programming with fonts, e.g. to produce randomness, especially when combining with web), so I have sticked with FontLab Studio, the first version of which I purchased already years ago. But it seems that at least from programming perspective interesting things happen also (and perhaps mostly) elsewhere (at least on macOS, Glyphs and Robofont seem to be the most popular, and FontForge seems also have a good scripting support). 


  14. As AI shares common object model with InDesign, perhaps they just wanted to boast and show that it is basically possible (even if painful)!

    Because of the common ground InDesign also has internal support for certain useful AI things that are not implemented in the UI but can be invoked via script. They basically could have just one app that does what InDesign and AI do, in one package. But will hopefully never do that. It is not a big  deal switching between the apps, and it is far better to be able to produce AI and (Illustrator-editable) EPS files (and PSD files, for that matter) that can be shared with the whole industry than having one gigantic proprietary format that only Adobe apps can open and render accurately, and the rest just guessing.


  15. Related to this, I installed Nadyezhda SL One from Adam Twardoch's site at http://www.twardoch.com/fonts/, which has all OpenType features included to allow easy testing of any application's OpenType support, and ran a test on Affinity Publisher and InDesign.

    Both apps seem to have more or less the full set of OT capabilites supported (not all can be simultaneously enabled because there are mutually exclusive features), but intrestingly Affinity Publisher does not seem to have them all listed in the UI. E.g., the positional marks and localized forms specific to this font (Tengwar Parmo), shown here as tables LOCL, MARK and MKMK, are not listed in the UI and cannot be turned off if wished. I wonder why?

    opentype_capabilities_apub.jpg.6271ce83428b8eb50c0bcb3a9ffbf1e1.jpg

     

    opentype_capabilities_id.jpg.73cabd3348e85452f0f219da2c1fd6e6.jpg

     

     


  16. 5 hours ago, Steps said:

    I never understood why InDesign and Photoshop are so different regarding basic features. The code base must be 100÷ distinct with no shared kernel at all to get those effects.

    The Affinity concept is really better here.

    It may work well in short documents. ID and Illustrator document object models are to some extent identical, and it makes sense in these kinds of apps to have common object model, but not so much when you work primarily with bitmaps. You can see the benefits if you handle long documents in InDesign and Affinity Publisher. It is pretty much desperate in Publisher, at the moment.

    Also, as regards variable fonts, I am very interested to see how this will be implemented in InDesign, that is, will only predefined instances be supported, or fully linear adjustments of all supported axes. As this is clearly a bit different challenge in a page layout app, than it is in an app like Ilustrator that basically focuses on "artistic text" (vs. column text), or Photoshop, that ultimately typically renders the text as pixels.

    In addition, there is some point in keeping things separate, considering the risk of combined data getting corrupt, or resulting in bloated file sizes. But there are of course benefits, as well.


  17. Ok, then it seems less likely that this is in any way affected by a security feature like Windows or Bitdefender watched folders that control's "suspicious" file activity (as this typically involves only access to standard paths).

    I have created now a 300 page document with about 220 pages text and about 100 print-quality photos (producing a very manageable file size of 32MB), in purpose of testing how Publisher copes with such a document (seeing if the file gets absurdly big at some point, as there have been reports of these kinds of problems, or if it gets corrupt at some point when editing and saving the content), but so far no problems. However there seems to be some law according to which such test files never fail, and when I actually need to deliver something real, only then things get broken. Anyway, to add the risk for vulnerability, I have placed this file under the standard system dcouments path.


  18. 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.

    tenwar_id.thumb.jpg.0aca566f71e5bc4291c9c159d386ddcf.jpg


  19. 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)..

×

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.