Jump to content

sfriedberg

Members
  • Content Count

    146
  • Joined

  • Last visited

Everything posted by sfriedberg

  1. It's the fundamental way that graphical styles work in CorelDRAW, and I routinely adjust stroke and fill properties on hundreds or thousands of objects at the same time, having assigned them all the same graphical style, by editing the properties of the graphical style. There are major differences between Affinity's treatment of graphical styles and CorelDRAW's. Corel's styles are defined in the document. You can export and import graphical style sheets (sets of styles), but they aren't global across all documents. Affinity's styles have many, many more properties than Corel's, basically all the layer effects stuff. Corel's are "live", like text and character styles in both apps, while Affinity's are more like templates, applied once but not associated with the object after application. So it's certainly possible from a technical perspective, and practical to implement and use, but I have no idea if Affinity has any intention to move in that direction. I would like to see graphical styles in the Affinity suite be "live" as in CorelDRAW, but with the current full set of features and the addition of various scale-with-object (present in CorelDRAW) and transform-with-object checkboxes to control how strokes and fills are affected by object transforms.
  2. Related to gradients between spot colors, it would be nice to have a duotone/tritone color separation (screening) capability. I used to use a plugin for Corel PhotoPaint years ago for poster and postcard work, and it was pretty marvelous to see full-color images separated out as spot color plates.
  3. Not at the moment, no. There is no plugin architecture, there is no scripting support, and there is no data merge capability. At present.
  4. Also interested in this topic. I have a PA239 (10bit) sitting right next to a PA238 (8bit) with a 10-bit capable Quadro adapter. I use the 239 for color grading and similar tasks.
  5. I had a similar issue, which apparently was due to inconsistencies among the fonts in the installed font family. That may or may not have anything to do with your problem, @Olli O .
  6. I want to return to Ulderico's original point, which is that tables do not play well with the global baseline, rather than critique the documentation. I agree with his point completely, to the point where I usually set tables to ignore baselines (global or from the surrounding text frame) because the results are terribly erratic, and simply live with table rows not being uniformly aligned with the body text. There may be a successful recipe that involves setting table cell insets to zero, or something like that, but so far I have not had both the time and the inclination concurrently to search it out. So the point is that the "out of box" experience is frustrating, ugly and to be avoided.
  7. Yeah, a lot of programs which open CorelDRAW files open really old versions only. That's typically not a problem in practice for applications like vinyl cutting or embroidery design (two niches where CorelDRAW is the dominant app). But you do have to explicitly "save as" in CorelDRAW using a version that your partner/vendor can handle. I should say that version X4 (14) is fairly comprehensive in features. By "really old", I meant something like version 5.
  8. Coming from the CorelDRAW world, the confusion and disagreement about terms in this thread bothers me a little bit. Speaking mathematicallly, not in reference to any particular drawing program 's UI, the handles at a node define the tangent to the curve at the node. The distance of the handle from the node also affects how Bezier curves are shaped, but as long as the handle is in the same direction, the tangent at the node is the same. As the handle-to-node distance decreases to zero, the contribution of the tangent to the resulting curve gets less and less, so that you cannot distinguish a such a handle from a missing handle. So it doesn't matter to the resulting curve whether your drawing program's UI treats it as a missing handle or an explicit handle at distance zero. In both cases, you can draw exactly the same shapes. So this is literally a distinction without a difference. If you have a curve segment with missing handles on both end, the result is a straight line segment. If the curve segment has a handle on one end, and the handle is not colinear with the two endpoints, then the direction at the other end is a type of natural end condition for a Bezier curve. Now draw out a handle from the other end, keeping it on the same tangent line as the natural end condition. As you increase the handle distance, the shape of the Bezier curve will change, while keeping the tangents at both ends unchanged. One of the consequences is that if you remove a handle at non-zero distance, you necessarily change the shape of the curve unless you were starting with a straight line segment, in which case you could remove the handles at both ends. Martin's request seems perfectly reasonable to me.
  9. I've noticed that several of my "math" fonts have illegibly small glyphs in the Glyph Panel, even when the largest glyph size is selected in the hamburger menu. Easiest possible example on Windows would be to compare the two fonts Cambria and Cambria Math. I also see the problem with DejaVu Math Tex Gyre (compare with DejaVu Serif) and Latin Modern Math (compare with Latin Modern Roman12). Interestingly, I do not see the problem with Segoe UI Symbol or with Libertinus Math, and the latter is certainly a full-fledged "math" font. I'm not an expert on OpenType font encoding, but my (very limited) understanding is that "math" fonts have some additional/different metric tables to facilitate the more complex job of setting mathematical expressions. The Glyph Panel doesn't seem to handle the result very well in some circumstances. Once selected, the math glyphs display in a text frame at the proper size; the issue only involves the Glyph Panel, both the display grid and the window of recently selected glyphs at the bottom. Hopefully, the examples I gave above of fonts that do, and do not, show the problem will help narrow things down. Windows 7 Pro and Windows 10 Enterprise, AffPub 1.8.3.641. Before moving this over to the bug reporting forum, can anyone out there confirm the problem?
  10. Corel releases their graphic suite every year, but as you can imagine after 20+ years, most changes are pretty small. One of the most significant changes since CorelDRAW 5 (which is when I started with it) is the addition of real color management, and one of the biggest improvements several releases later was when they completely reworked both the UI and the color management engine. Massive lesson learned: If you are going to do real color management, do not automatically, quietly, helpfully, do anything hidden from the user. Color management is already too complicated. Making silent conversions because it's "convenient" and "probably what the user wants" just produces a hair-pulling nightmare for the user and endless inquiries on support forums. Make all the profiles and color models for all the sources/sinks (scanners [plural], monitors [plural], printers [plural], JPEG images, PDFs, etc) explicit. Make all the transformation pathways explicit. You can assign default values to those things, or take their assignments from the OS or input file metadata, just don't hide them! And let the user install additional profiles and assign them explicitly. And let the user reset the profile for a specific source/sink to whatever the default was, without having to memorize it or use an external tool to read metadata or interrogate OS color management profile assignments. I'd point out that Adobe didn't get this right for a long time, either.
  11. Well, no, the thrust of my comment was about a behavior you cannot get today with the Node or Point Transform tool. The Point Transform tool comes much closer, but it is limited to adding one point for the duration of interactive transformation of the object itself. It does not create persistent new anchor/snapping points on the object to which other objects might be aligned (or connected if/when the Affinity suite gets connectors). And it does not add multiple snapping points during an interactive transformation. The Visio functionality can be thought of as a variant Node tool where you can add any number of anchor/snapping points to an object, not limited to being on any curve or limited to any particular geometry. In particular, you can put them a 1/4" (or a foot) outside your object. These points are persistent until explicitly deleted. They can act as snap points when transforming the object using the regular transform tools. They also act as snap points while you are transforming other objects. And connectors (the subject of the original request in this thread) anchor to them, so the anchored end of a connector moves with the object when you transform it.
  12. Corel PhotoPaint has a mode where you can paint in greyscale (black, white, or in between) on a mask or channel layer.
  13. I'd like to add a tiny bit to this request, or perhaps a starting point. The ability to add manually snap points to an object/layer in addition to those automatically defined by its geometry is very useful, even in the absence of persistent connections. I frequently have complex shapes that need to be snapped to guides, other objects, etc., but at points that are not automatically defined. For example, on the convex hull or in the interior (but not the exact midpoint) of the overall shape. In Visio, for example, you can manually add anchor points to an object anywhere you like (including outside its bounds or in its interior) and these can be used for snapping and alignment as well as connection endpoints.
  14. Emphasis added to the original to promote clarity of reading.
  15. Everybody has a favorite scripting language, Frank. But no scripting language is everybody's favorite. In practice, the Affinity document/object API and its binding to the scripting language is going to be far more significant than the language itself. An incomplete, poorly organized and badly documented API/DOM will be agony to use in any scripting language. Conversely, a comprehensive, modular and well-documented API/DOM will be easy to use in any scripting language. We don't need Serif to give us Python, or Lua, or Perl, or ECMAScript, or FORTH, etc. We need them to give us an API.
  16. @Gabe Tried to send you a message, but "Gabe cannot receive messages". So adding this post with an at-Gabe to generate a notification.
  17. I'm with Lorox. I loathe Visual Basic for Applications, but I have written a number of scripts in it because it's what the applications in question supported. Everybody has a favorite scripting language. If you wait long enough, most of them will vanish into the misty past of trendy tools with no longevity. I don't even try to predict the exceptions, and use whatever is available.
  18. @Gabe I've been off line for a week, sorry for the delay. I am not sure if I have more font families with such a large number of fonts. Usually "big" families were packaged/metadataed (can I use that barbarism?) so they were grouped into several smaller families. However, I think I have at least one other font family of similar size. When I get to the affected computer, I will investigate and report back. [Added in edit] The next largest font family I had installed is Scansky with 28 fonts. It works OK. I went back to Google and downloaded Noto Serif Display. I've never had this font family installed on this machine before, and it has 72 fonts organized just like Noto Serif. All 72 Noto Serif Display fonts installed and appear in Affinity Publisher with no problem, while Noto Serif gives me either 4 or 68, apparently dependent on which ones the Affinity suite sees installed first. So, I went back to the well. I did not record where I downloaded the zip file of the Noto Serif family on 14 June (possibly FontSquirrel?), but that archive contains a mix of version 1.02 and 2.000 fonts. If you go to https://fonts.google.com/specimen/Noto+Serif you find only the v1.02 "group of four" (which seems like a defect or a seriously out-of-date page in Google's website). Today, I went to https://www.google.com/get/noto/ and got another zip archive of Noto-Serif. This one has all 72 v2.000 fonts. When I uninstalled the v1.02 "group of four" and installed the v2.000 "group of four", the Affinity suite sees all 72 fonts in the font family. My problem solved, and your problem partially identified. Back in 2017, when Google did a big expansion of their font collection, there was a note to the effect that older font releases could not be merged with newer ones. While they were all TTF files, the new phase 3 fonts are based on a 1000 upem grid while the older phase 2 fonts were based on a 2048 upem grid. I am sure this is part of the version 1.x to 2.x transition. I also went to the non-standard and unreleased https://github.com/googlefonts/noto-fonts-alpha/tree/master/from-pipeline/unhinted/ttf/serif/NotoSerif which has version 2.001 fonts. These also work together in a test install mixed with the version 2.000 fonts. So, I conclude that the Affinity suite on Windows 7 does not find the 1.02 and 2.x versions of the Noto Serif font family compatible, where other apps running on Windows 7 find them tolerable together. Precise reason to be determined, but it would be worth adding this to your diagnostic checklist in case some future user has a similar complaint as their problem can be resolved even if Affinity developers do nothing more.
  19. Sending a chip (that isn't too old, and thus faded) to a printing company is good insurance, but it should not be necessary with a reputable printer. They will order (and possibly mix) the actual Pantone ink based on the Pantone code. They should not be doing a colorimetric match using a different (non-Pantone) pigment set.
  20. You could try rotating the group first, then select the (rotated and translated) members of the group, turn on Transform Objects Separately, and then rotate them all back, leaving them at their new locations and old orientations. I.e., if you rotate the group 30 degrees, rotate the members -30 degrees. While this isn't automatic, it will let you correct the rotation of all the group members in one step, instead of doing each one sequentially.
  21. In total? It depends on what I am working on. At this moment, the Windows Font folder says 649 items. I believe that includes both directly installed and shortcut installed fonts. The latter are in the registry, but do not actually reside in C:\Windows\Fonts .
  22. I have one additional bit of information to add. I went over all 72 .ttf files with every tool I had, and found that the version number for the 4 fonts is "1.02", while the version number for the 68 fonts is "2.000;GOOG;noto-source:20170915:90ef99883387c0". I went back to Google and checked the available files again. In the 72-font family download package, those are the versions you are given in today's download. In the Google specimen page for Noto Serif, where only regular and bold weights are shown, you get the 1.02 version only. I don't know if this is relevant to the behavior of the Affinity suite, but it's the only thing I can find that distinguishes the two disjoint sets of fonts.
  23. I'm reporting this for Publisher, but Designer and Photo are also affected. Windows 7 Pro 64-bit. Affinity Publisher 1.8.3.641. I recently installed 72 TrueType fonts of the Google font family Noto Serif -- Regular, Semicondensed, Condensed, Extracondensed -- Thin, Extralight, Light, Regular, Medium, Semibold, Bold, Extrabold, Black -- Roman, Italic. Publisher saw 68 of the 72 fonts. It was missing the exactly the most heavily used ones: regular weight roman and italic, and bold weight roman and italic. On the same system, CorelDRAW 2018, LibreOffice Writer 6.4.1.2, and Rhinoceros 6 SR15 see all 72 fonts, as do Workpad and the Windows Fonts directory. In fact, every application I've tried that has a font drop-down list sees all 72 fonts, except for the three Affinity apps which see 68 of them. In Publisher, the Character panel and Text tool context font drop-down actually count 68, while in the Text Styles > Font panel, the font traits drop-down is missing regular and bold. I un- and re-installed fonts, removed the Windows font cache and restarted the system several times, to no apparent effect. My first suspicion was that 72 fonts organized under a single font family was too many. So I removed some, then many, of the fonts, with no apparent effect on the four missing fonts. I then removed all fonts of the Noto Serif family, rebooted the system, and installed only the four affected fonts. This time Publisher saw the four fonts. So I installed the rest of the regular width Noto Serif fonts, for a total of 18. Now Publisher sees only those first four, which is the opposite of the original problem. Restarting the Windows Font Cache service had no effect. Rebooting the system had no effect. At this point, there are definitely 18 fonts of the Noto Serif font family installed. All the other applications on this system see all 18. The three Affinity apps only see four of them. Now, if some other applications were showing similar symptoms, I would conclude that something in Windows font management was messed up. But only the Affinity apps seem affected, and they are effectively in sync, which lead me to suspect there is some suite-level caching going on which is out-of-sync with the system state. I went poking around in AppData and the application installation directories, but did not find a smoking gun. While writing up this message, I installed the additional 18 fonts in the Noto Serif Condensed sub-family while Affinity Publisher was running. Publisher displayed its usual pop-up message that the font cache was being updated, so it was clearly responding to system events related to the system font cache. However, when I looked at the font drop-down in the Character panel, only four of the Noto Serif fonts were listed. Keep in mind that originally 68 of the 72 fonts were shown in Publisher in exactly this place, so no inability to display more than 4 fonts is involved. So, I uninstalled all of the Noto Serif fonts again and restarted the Windows Font Cache service, while Publisher was not running, then launched Publisher. As hoped, no Noto Serif fonts were listed in its font drop-down list. I then shut down Publisher again, and installed all 72 of the Noto Serif fonts, then relaunched Publisher. It shows 68 out of the 72 fonts, missing once again regular weight roman and italic and bold weight roman and italic. I repeated the uninstall of all Noto Serif fonts, restarting the WFC service, while Publisher was not running, launched Publisher and verified no Noto Serif fonts were listed. Shut down Publisher. Install just the 18 regular width fonts. Restart WFC service. Relaunch Publisher. It shows 14 out of the 18, missing regular weight roman and italic and bold weight roman and italic. Uninstall all the Noto Serif fonts, restart WFC service, while Publisher not running. Install just the 18 Condensed subfamily fonts, restart WFC service, relaunch Publisher. It shows all 18. Shut down Publisher. Install additionally just the regular width, regular weight roman and italic, restart WFC service, relaunch Publisher. It shows only the 18 Condensed fonts. Uninstall all the Noto Serif fonts, restart WFC service, while Publisher not running. Install just regular width, regular weight roman and italic, restart WFC service, relaunch Publisher. It shows those two fonts. Shut down Publisher. Install additionally just the regular width, bold weight roman and italic, restart WFC, relaunch Publisher. It shows all four fonts. Shut down Publisher. Install additiionally just the 18 Condensed subfamily fonts, restart WFC service, while Publisher not running, relaunch Publisher. It shows only four fonts: regular width, regular weight roman and italic and bold weight roman and italic. At this point, I started banging my head on the desk. When I was done shouting incoherently, it became clear that the Affinity suite will allow me to have either the four most basic fonts of the Noto Serif font family, or any of the other fonts in the family, but not any mixture of those two disjoint sets. I have no theory about what's responsible for that! And I repeat that no other application on this system which possess a font drop-down is having this difficulty and all of the installed fonts are plainly visible in the Windows Fonts directory and every single one of those fonts can be previewed by the OS and set as a text property in the other apps, and every single one of those fonts looks like the right width, weight and letter form appropriate to the font name. To forestall some well-meaning but irrelevant questions: This system is not short on disk space (94GB free on the C drive, 375GB free on the D drive where the applications are installed, drives E, O, P and Q are not relevant to this problem). This system is not short on RAM (6GB in use out of 64GB physical). Installing fonts "directly" or via a shortcut has no impact on the problem. If anybody has any suggestions as to cause, or requests for additional experiments to run, I'm open to almost everything. I will not even bother to respond to a suggestion that I reinstall the operating system on this machine. I am open to some judicious and well-explained registry hacking, but 1) nothing in my research indicates that any sophisticated feature of the Windows registry is involved here. In particular, font linking and system level font substitution are not in play. And 2) no other application on this system is showing this behavior.
  24. Unfortunately, I didn't run across this particular forum thread until I filed it again.
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. 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.