Jump to content

fde101

Members
  • Content count

    2,361
  • Joined

  • Last visited

Everything posted by fde101

  1. yep There are plans to address this with a new layer type in the future.
  2. With a plugin model, presumably the Affinity applications themselves would expose a common document model to the plugins, so the existing Serif code would handle those details and the plugins wouldn't care. I agree that supporting file import/export plugins would be a nice plus, and should be quite feasible.
  3. @JerytheKID, welcome to the forums! No, Serif does not generally provide timelines for when specific features will be implemented.
  4. fde101

    Scripting

    In this case it simply won't be possible for some people to meet their requirements. I've never seen ANY evidence supporting this common theory. No scripting solution that can integrate multiple applications across an environment can be at this point due to security restrictions within the OS. To fully meet the requirements of production workflows on both platforms, this will almost certainly be necessary. Yes, it is. Unfortunately not possible to do in isolation. As I explained previously in the thread, there are two major use cases here with different and currently conflicting requirements: The ability to script within the application. This can be done with a cross-platform scripting language which could be selected by the Affinity team and integrated into the product; I proposed Lua due to the fact that it is engineered for this purpose and is likely to have the fewest security hazards and be the easiest code base for the Serif team to maintain - others seem to prefer ECMAScript (JavaScript) which has interesting semantics in a few places (but the syntax stinks) while others clearly prefer that snake thing for some incomprehensible reason. Using a common language across platforms for this has the benefit of allowing scripts to be written once and shared by users on multiple platforms. The ability to combine multiple applications. This cannot be done with a language integrated into the product and must use a solution provided by the host operating system. In this case, to support the needs of users integrating applications within their workflows, there is no choice. For the Mac, it must be OSA (AppleScript); for Windoze, it must be WSA (VBscript I think?) Note that much of the work required to provide this support, if carefully designed, can be done in such a way that all of the requirements could use a common base within the application code, minimizing the amount of effort to support multiple scripting languages (and a plugin interface). If a system is set up internally which exposes a "document model" that is common to plugins and to the various scripting languages, then the general scripting support could be implemented internally once, and the various languages and the plugin interface could hook into that common model. In this way, most of the "application" side of the scripting interface could be coded and maintained separately from the specifics of the individual scripting languages (OSA, WSA, Lua/Perl/Snake/CrypticThingUsedOnTheWeb/etc.) and from the native plugin interface. Then people who wanted to use the internal scripting language could do so, those building workflows across applications could use OSA/Applescript on the Mac or WSA on Windoze, and native plugin writers could hook off of the same document model. As the applications expand and add new capabilities, Serif would only need to update the document model once and plugins and the scripting languages would all fall in line.
  5. Make sure the color profile set for the document is correct (in Document Setup -> Color). That would be my first guess.
  6. I don't believe this is related to the export format. Affinity Photo does this internally without even exporting - I made a video to demonstrate this which is on another thread:
  7. fde101

    TARGA file please?

    Thanks, I hadn't noticed that bug post until now. I didn't add one because I don't recognize this as a bug. It seems to be an intentional design choice in the engine, and not related to the export format, as it happens without an export. I was responding as part of an explanation of a post already on this thread, which is why it is here. Nevertheless, I will link back to this from that bug post as it does appear to be related.
  8. fde101

    TARGA file please?

    Actually, the brush is a bad example - shapes are more telling. Here I created three rectangles filled with one shade of blue, and three with a sort of greenish shade that still has some blue in it. I gave all of them white strokes so that the strokes would stand out when looking at all of the channels. opacityZero.mov Note that in the end, looking at the blue channel only, the rectangles with 100% opacity and the ones with 1% opacity look exactly the same, but the ones with 0% opacity disappear (except for the white strokes). You can see from this that the channel in general is not pre-multiplied - it is not reflecting the 1% vs. 100% opacity - but there is something about the implementation that is causing the 0% opacity to drop off. You can also see that the two different colors are reflected as different shades in the channel, so it is not showing the channel as a black/white mask or similar: it is reflecting the actual channel values. This is NOT a PNG vs. TGA issue - it is something in the implementation of the alpha channel within Affinity Photo itself.
  9. fde101

    TARGA file please?

    The PNG and TGA file formats are both defined as NOT pre-multiplying the alpha channel. As both are also lossless formats, if PNG is being exported without the added transparency data, there is no reason to expect it would be any different for TGA. This is a software implementation issue, not a characteristic of the file formats. Try this: in Affinity Photo, create a new document with a transparent background. Switch to the brush tool, choose a blue color, with opacity at 100%, draw a quick vertical stroke somewhere on the canvas. Then keep the same blue color selected but reduce the opacity to 0%, and draw a second stroke right next to it. Go to the channels panel and turn off the visibility (eye icon) of all channels except the blue one. You will only see *one* brush stroke. When opacity is at 0%, the color data is not even being recorded by Affinity Photo, so there is nothing there to export. It is not just brushes either: the same thing happens with shapes. Affinity Photo is "optimizing away" anything with 0% opacity internally, so it doesn't matter what format you export in - you will see this same behavior.
  10. It is only subscription on the app store - if you purchase off their web site there is a perpetual license available: https://www.coreldraw.com/en/pages/ppc/coreldraw/mac I wish Apple would go back to forbidding subscriptions on the app store; they are resulting in lots of issues like this. Right now CorelDraw on the app store has a two star rating out of 60 ratings and most of it (if you read the comments) is from might-have-been-users complaining about the subscription model.
  11. I would suggest adding an "insert" icon to the context toolbar somewhere that could be dragged into the table where you want a row or column inserted. Much as there is a hint line in the layers panel as to where a layer is being moved, as you drag that icon into the table, it could draw a horizontal or vertical line to show you where the new row or column will be added.
  12. Betas downloaded from the forum will activate if you have the MAS versions of the released apps.
  13. I don't think the right alignment for the set of instructions is doing this any favors for readability. It might look pretty from a distance but from a practical standpoint, if I received something in that form I would most likely either discard it completely or rewrite it myself to make sure it wasn't slowing me down every time I went to check something while trying to use it.
  14. This is not really related to StudioLink, it is a function of how linked "embedded documents" work in the Affinity applications right now. Currently, embedded documents which are "linked" are actually still embedded, but the applications watch for changes to the external file and offer the ability to update the embedded copy when there are external changes. When you try to modify the "linked" document within the application, it updates the internal copy but not the original file. I believe the plan is to have these documents more correctly linked later on, similar to the way that linked images work, so that there won't be a separate copy of them embedded into the main document any longer. My guess is that this issue would be addressed as part of that effort... but I suppose we will find out when it happens.
  15. fde101

    Affinity Video Editor?

    Ah... ok, I missed that OpenShot has that capability. Maybe I need to take a closer look at that one (though personally I generally would just use Resolve in most cases)... if @dsac is in fact doing motion graphics work then I agree that it makes sense to get SVG working; if just taking artwork and putting it onto the timeline as a clip, then I would reduce the hassle and just use a raster format.
  16. fde101

    Affinity Video Editor?

    Why are you exporting SVG for use in a video editor? I would just use a raster image file instead. We aren't quite at the point where video is being exported in a vector format anyway
  17. Perhaps the controls should be disabled when an arrowhead is applied in order to make this a bit more clear to the user?
  18. Agreed - if the book feature is missing, it may be inconvenient for some workflows, but it does not prevent quality work from being accomplished. #1 + #2 are the biggest showstoppers for a project like this. #3 is a bit more open to debate but is not clearly necessary (though the work may very well benefit from it if available).
  19. Just to verify, is Publisher also at 1.7.1?
  20. @Bugbob, welcome to the forums! You might want to consider doing a search before posting new topics for obvious requests like this; this particular one has a number of them already, and Serif has already indicated they are working on producing a DAM application, though we don't have any specifics on it yet (features, timing, etc. - we'll find out when we find out).
  21. It looks like there may be some patents involved with the compression this format uses? https://github.com/lclevy/canon_cr3 https://www.fredmiranda.com/forum/topic/1586395/1 Nevertheless, it looks like libraw intends to support CR3 sometime in the fall: https://community.skylum.com/hc/en-us/community/posts/360048005532-v3-1-2-again-still-no-CR3-support-
  22. Agreed - I don't have much trouble navigating it because of that, but there is plenty of room for improvement (for Apple's System Preferences too - they should take a cue from the Control Panel they had back in the days of System 4 through System 6; it was much better overall - for those not familiar: https://www.versionmuseum.com/history-of/classic-mac-os). "Modern" macOS derives from NextStep, which used a somewhat similar design to the one from System 4-6 (the icons for the individual preference panes are horizontal as opposed to the vertical list of control panels used in System 4-6): http://toastytech.com/guis/openstep.html
  23. fde101

    open files are upside down.

    Considering that the numbers on the rulers are reversed in the screenshot this does appear to be related to canvas rotation.
  24. You can group the layers then rasterize the group?
  25. Just curious: how much value is there in a Japanese translation of the UI when there is no vertical text support?
×