Jump to content
You must now use your email address to sign in [click for more info] ×

v_kyr

Members
  • Posts

    12,556
  • Joined

8 Followers

Recent Profile Visitors

11,336 profile views
  1. It has to take (show up) those from a disconnected monitor then ideally over to the main screen/monitor with/by applying the default window size setups for the initial used main screen. - Pretty much similar, but in a better & directly programmed automated task, of what above referenced FAQs tell to do manually instead.
  2. The app either way keeps track of window sizes and their positions etc., additionally it has to check for the external monitors availability (connected/disconnected) and if a before used monitor is disconnected then remap & arrange the windows over to remaining connected ones instead. - Further as an OS already offers via it’s accompanied prog APIs & libs all the related monitor detection & window handling functions etc., it‘s more a matter of making the right use out of these here for this context.
  3. Of course there are programmatic ways under macOS to detect how many monitors are connected and to react on newly connected or disconnected monitors, thus also triggering external monitors. A bunch of macOS third party apps do handle this in a graceful manner. Further one can also easily deal with that via scripting if wanted, just one two simple AppleScript examples here … https://apple.stackexchange.com/questions/333556/how-do-i-trigger-a-script-when-a-second-monitor-is-attached
  4. The Affinity SVG parser probably doesn't know how to interpret the SVG <pattern> element and thus omits it. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/pattern <svg viewBox="0 0 230 100" xmlns="http://www.w3.org/2000/svg"> <defs> <pattern id="star" viewBox="0,0,10,10" width="10%" height="10%"> <polygon points="0,0 2,5 0,10 5,8 10,10 8,5 10,0 5,2" /> </pattern> </defs> <circle cx="50" cy="50" r="50" fill="url(#star)" /> <circle cx="180" cy="50" r="40" fill="none" stroke-width="20" stroke="url(#star)" /> </svg>
  5. As far as I recall Affinity's SVG parser doesn't take the available SVG text attributes into account, aka it doesn't know to make any use out of those. There should be some older related forum threads about the Affinity SVG text behavior theme. - Thus you best here arrange (center) the text in ADe and then export as SVG, which will generate and adjust the SVG text x/y coordinate dependent to the document dimensions (SVG bounding box size). <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100%" height="100%" viewBox="0 0 1000 1000" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;"> <text x="150px" y="765.65px" style="font-family:'HiraginoSans-W4', 'Hiragino Sans', sans-serif;font-size:700px;">☂</text> </svg>
  6. See related to SVG … https://vecta.io/blog/using-fonts-in-svg … though the Affinity SVG generator & parser won‘t support everything SVG can deal with here. If you don‘t have to change the text and font type often on occasion, you can also convert text to curves instead, before saving the whole then as SVG.
  7. As APub is a huge memory hog (RAM and disk memory wise) when used for some none trivial things. Your info pointing just shows the initial mem size marketing tells for running the app, not what happens mem wise then when you create and feed in some greater doc with many pages etc. - Just search over the forum for APub used by people on M based hardware in conjunction with occupied memory size growing over working on document iterations.
  8. See … https://forum.affinity.serif.com/index.php?/forum/9-tutorials-serif-and-customer-created-tutorials/
  9. Check that the USB disk is not FAT32 formatted, since FAT32 cluster size is limited to 4GB-1, or exactly 4,294,967,295 bytes. So if a file is larger than that, the FAT32 file system can't store it, and an attempt to transfer large files to a FAT32 formatted drive gives an error. - Thus use exFAT formatted USB devices which then do support file sizes up to 128 PBytes.
  10. Try out OpenGL instead of Metal under the APh preferences performance settings.
  11. For Affinity the minimum to start & use the app. Now if you add a bunch of contents (huger images & drawings etc.) let‘s say for a >100 page APub (aka the suites greatest memory waster app) and apply some operations on these, it‘s memory usage will be factor x of that for RAM & doc‘s used disk space. For IDEA add some common needed dev plugins, aka some Java/Kotlin based Frameworks/libraries and other services stuff (from Maven repositories, db and utility help stuff etc.). Then during project work, indexing, runtime & build processes having only 8 GB of RAM is nothing and no fun (nearly impossible) to have to work with. - For the distributed systems project stuff I usually tend/have to deal with in daily practice, having an M-based Mac with at least 24/32 GB of RAM is needed.
  12. Then you probably do (and always did/run) only small/tiny things or project related stuff here. - If I fire up an Affinity app, together with an Jetbrains dev IDE & image + database server, FF and some smaller tools, I would go nowhere with just 8 GB of RAM. Things then would rapidly slow down and the system would often stall due to too much I/O swapping.
  13. Then you may don‘t run other huge apps in parallel, I always do and need to. The Affinity apps are known to often have problems when dealing with direct access to external/remote data file storage like NAS drives. Further having always to copying files first back and forth due to too small sized SSDs isn‘t fun and something which offers an overall fluid workflow, no matter if at work or home. Thus it‘s overall better to always have some more RAM and storage space in reserve here if urgently needed by certain project processings.
  14. This “more” somehow suggests that there would already be some kind of Serif-based documentation for creating plugins, which unfortunately is not the case here. All legacy PS C++ Plugin API documents come from Adobe or other third parties. There is nothing that Serif has ever published about this materia, which by the way is pretty weak and a disgrace.
×
×
  • Create New...

Important Information

Terms of Use | 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.