fde101
-
Posts
4,985 -
Joined
-
Last visited
Posts posted by fde101
-
-
4 hours ago, A_B_C said:
documents based on an improperly encoded math font
Just so I understand this clearly... the concern is that Publisher is treating invalid fonts as being invalid?
-
-
You can do at least the first three already using the move tool after making your selection.
To set the rotation point, turn on the "Enable Transform Origin" button on the context toolbar, then drag it to where you want the rotation to anchor. To use that same point to scale around, hold down the command key (on Mac - if you are using the other platform check the status bar for what key to use) while dragging one of the handles.
Depending on what you mean by distortion, if your selection is not an entire layer try Layer -> Duplicate Layer to make it into one, then try either the Mesh Warp Tool or the Perspective Tool; one of those might do what you want?
- debraspicher, IPv6 and Momento
-
1
-
2
-
Hi, @dmopell, welcome to the forum!
By AFP do you mean Affinity Publisher?
You posted this in a section of the forum for discussing Affinity Designer, which is a separate program.
There are already a number of threads discussing footnote and endnote support for Publisher, and the short version is... eventually.
-
9 minutes ago, JGD said:
namely variable fonts?
And spread the discussion out even more than it already is, making things even less likely to be noticed when they do get around to it since they will be all over the forum rather than consolidated in once place?
Why not keep it together in one of the numerous threads that already exist on that topic?
Personally, I am much more interested in support for SVG fonts than for variable fonts, but I do think both should be seriously considered and supported at some point. As has been repeated a few times, however, it seems this won't be happening particularly quickly, and I don't expect that piling additional discussion on top of what has already taken place is likely to change that.
-
38 minutes ago, v_kyr said:
a scripting support for whatever scripting language has to be platform/OS independent here
I wonder how many times I might need to repeat this before it sinks in...
Scripting languages which are built-in to the application cannot readily interact directly with other applications.
Particularly in a sandboxed security environment such as MacOS apps from the app store.
As a result, a 100% cross-platform implementation cannot support workflows that interconnect multiple applications - you must use a mechanism provided by the OS to support that, and those mechanisms by nature tend to be OS-specific.
Refer to the post by @TonyB above for one possible option for dealing with this. It would provide an in-app scripting language which would be cross-platform for those scripts which do not require interaction with other apps, but allow the OS-provided scripting architecture to hook into it just enough to make it possible to interconnect multiple applications for those who have the need to do so.
46 minutes ago, v_kyr said:the write once run everywhere principle
Sounds great in theory, but doesn't always pan out in practice. HTML, ECMAScript, CSS are supposed to be open standards to allow for consistent interpretation between browsers, but look at how many sites work well on one browser and not on another... and different operating systems and environments are by nature different. In many cases, something that is intended to work well on all of them is doomed to work poorly on all of them unless it is separately optimized for each one. Same thing with SQL code transported between database engines, etc.
-
17 minutes ago, v_kyr said:
Hmm reminds me somehow to ...
- osascript -- execute OSA scripts (AppleScript, JavaScript, etc.)
Yes, technically the scripting architecture in MacOS is not limited to AppleScript and can support the use of other scripting languages at the OS level as long as a proper bridge is created for them. AppleScript is the most cleanly integrated one, but there are a few others around.
I believe the same is true for WSH, where VBScript and JScript are the "bundled" options from what I am seeing.
-
2 minutes ago, Old Bruce said:
Could, but doesn't.
I was being hypothetical: if the restriction were not in place concerning objects which are half-on the artboard, then this could be a problem, thus possibly the decision to make them behave as they do...
-
2 minutes ago, R C-R said:
But it is an element of a Text Frame.
So is the size of the frame and the stroke around the frame, but that doesn't make them text.
-
13 minutes ago, TonyB said:
How about Affinity supporting AppleScript but only for for coarse grained functions with execute JavaScript snippet as one of those functions?
Yes, I was actually just thinking about that, and that could work as long as there is a suitable mechanism for arbitrary data in/out (pass parameters to the in-application script and obtain a return value, or provide for file I/O or similar) and the implementation allows for syncing the execution of the script inside the application with the one running outside the application (ex. does not "return" to the AppleScript until the application's script completes). Definitely can't say I'm a fan of JavaScript (should really be ECMAScript if using that) but whatever that language is, from the standpoint of making it possible to interact with other applications in a workflow, it should be do-able that way.
Similarly with VBScript or whatever the Windows equivalent is.
-
3 hours ago, hi-ko said:
AppleScript should be seen as a nice to have
Some users are integrating multiple applications. A single-application scripting solution, no matter what the language, will not provide that level of integration. The only way to accomplish that meaningfully is with an external scripting solution, and for the Mac, that will generally be AppleScript. The ones on M$ OSes will similarly not carry across to the Mac.
This is one area where it is not feasible to have a cross-platform solution and still cover all of the bases.
Thus I think at least two scripting languages will be needed to cover all needs: one internal to the application (and thus cross-platform) and support for the common OS scripting language on each platform, for integration of multiple applications together within a workflow. For those users, AppleScript support is critical, not just nice-to-have, since any other option will not provide what is needed.
-
1 hour ago, walt.farrell said:
For objects that are partly inside and partly outside an artboard only the part inside the artboard is visible.
This kind of makes sense when an object can only be on one artboard at a time but multiple artboards may be presented within the document space.
If the object renders far enough outside the artboard as to overlap another artboard, it could appear to be on the other artboard, but then be missing from the layers panel when working on that artboard, as well as being omitted when exporting, leading to confusion...
Granted I haven't tested this scenario yet, but I suspect that might be what happens and could be the reasoning behind this design choice?
I'll need to play with this when I get a chance to see what actually happens...
-
15 hours ago, R C-R said:
if the document units is set to inches the width & height of the dividing line is still in inches instead of points.
Why wouldn't it be?
The dividing line is not text...
-
On 6/14/2019 at 11:36 AM, apepper said:
I'd love Photo to be able to import from a scanner
2 hours ago, apepper said:Using the scanner. I understand this difficult in Windows, but OTOH, PS does do it - I can read an image straight into PS from the scanner.
It already does in the Mac version. This is a limitation of the Windows version and from past discussion on this subject this is not likely to change quickly.
On 6/14/2019 at 11:36 AM, apepper said:The shadow/highlight tool doesn't seem to do as good as job as PS in lifting the shadows in backlit images.
You can achieve better results using the curves adjustment in the Affinity products.
-
21 minutes ago, haakoo said:
I get that,
I was referring to the straigthen option to get most done and rotate the child inside the crop area and afterwards crop>rasterise
Straighten is a rotation tool, it is not perspective correction. As an example of perspective correction, if you point your camera at a framed picture on the wall (to borrow the example used in the OP), but do not have the camera perfectly parallel to the wall, then one side of the frame will appear shorter than the other in your picture. Straighten can't fix that as it is a perspective issue - in Affinity Photo you would use the perspective warp tool or the perspective filter to correct for that kind of distortion. In most cases I would opt to use DxO Viewpoint (since I have it) and someone working in Photoshop might choose to use the perspective crop tool being referenced in the original post. Straighten can only account for rotation along the axis formed by the line from the center of the image sensor to the center of the lens.
-
17 minutes ago, walt.farrell said:
Can you help me understand the benefits of that approach? I wouldn't have thought it would make much difference when one did the perspective correction, or the cropping.
In terms of doing it in the RAW developer rather than in Photo, I prefer that mostly because I happen to have a more advance perspective correction toolset available using DxO Viewpoint and because Viewpoint is integrated into OpticsPro, so I can do one-stop-shopping, making it more convenient. It also allows me to do what should be a basic part of the development process earlier within the sequence of programs I am using. I don't know either that there is a technical benefit to doing it in one tool vs. the other if the tools have equivalent capabilities.
In terms of my preference for separate perspective and crop tools, from what I can tell in the descriptions I have found of the tool (and please correct me if I am missing something), Photoshop is determining the cropped area automatically after fixing the perspective, in order to chop off the "missing" parts of the picture? Assuming that is the case, if I am not using the entire area that results from having performed the perspective correction, it may be that parts of what get removed could have been left in as I would have been selecting a different portion of the resulting image anyway (which might not even be a rectangular area if I am masking the photo or placing part of it behind something else within a design) - so separating those tasks means I have the flexibility to keep more of the image than I might have been able to with an auto-crop.
If the auto-crop can be disabled in Photoshop, or if it is manually adjustable within the tool, then that reduces this benefit, but it is still only a small gain over using the separate tools.
-
18 minutes ago, haakoo said:
That is not the same thing.
What he is asking for is basically a combination of that tool with a perspective correction tool; in Affinity Photo these are separate tools.
Personally, I prefer making these kinds of corrections in my RAW development software before bringing the pictures into Affinity Photo, and even there I would be using the separate tools for it (as DxO PhotoLab + ViewPoint for example has at least three different perspective correction tools depending on the nature of what you are trying to fix, and I would rather have the added flexibility), but if you are one of those people who use the same program for both tasks, then this would make it marginally faster.
-
I could understand that making the labels blank or something, but removing the entire section of the interface? That seems a bit unusual...
In any case, I do hope they get added to the next beta.
-
On 11/23/2019 at 3:58 PM, Jesse L said:
I think it can still improve, and adding Image Trace is one particular way they can do that.
Yes, and I don't think anyone is arguing that point. The fact is that there are a LOT of feature requests floating around in which people are advocating very strongly that the product should never have been released without it, that they have gone several years without being implemented, that each of them should be the #1 priority, ...
Serif is a relatively small company with limited resources with which to implement these features (one of the reasons they can keep the price as low as it is for this quality of software), so they need to prioritize and select which ones make the most sense to implement in what order. They have already indicated quite strongly that they are hoping to implement this feature, but that when they do, they want to do it very well and it sounds like they planning on doing it in a very big way; they want to implement each feature with a relatively high level of quality rather than rush to get in lots of features that are half-baked.
That will take time, and with so many other things floating around that are much harder to work around or which are impacting a large number of users, it is quite understandable that this will not happen as quickly as some would like.
In this thread, several options have been suggested on how to go about doing this while waiting for Serif to finally get to the point where they can provide this feature. That is not because people think it is a bad idea, but because they are being more realistic about the amount of time it will probably take before it happens.
- Move Along People, SrPx and daKroad
-
3
-
Hi @ToniB, do you have any suggestions on how to make this more intuitive without making it less efficient or wasting screen space?
Many projects wind up with a large number of layers so expanding the UI to display things more clearly would likely use up more screen space which would make laptop users upset. Anything that required extra steps would make the process less efficient which would slow things down; as this is a professional-level application meant primarily for power users, efficiency of operation generally takes priority over obviousness for those first learning to use it.
If you can come up with ideas for improving the discoverability of the behavior or making it more approachable without compromising the efficiency or compactness of the current solution, your request is much more likely to gain some traction.
Personally the only thing I can think of at the moment would be to add some kind of indicator to the mouse pointer which depicts what is about to happen depending on where you are pointing as you drag the layer, and maybe highlight the drop zones somehow as well while doing so?
- Move Along People and ToniB
-
1
-
1
-
On 11/22/2019 at 3:54 AM, big smile said:
It would be also super handy if the layers panel had an option to only show layers on the currently active page of a spread, as sometimes the layers panel can get very chaotic to navigate when it shows all the layers on both pages of a spread.
Here you run into a complication when dealing with parent/child relationships. If you have a group containing layers on both pages, do you show the entire group in the layers panel, show the group but only the children on that one page (which might make it appear that the group is smaller than it is, causing both pages to lose content if you delete the group after only having seen objects from one page within it...), hide the group (since it contains content from the other page), ...
Also, what are you going to do with layers that are outside the spread and not on either page?
This is not the simple request you seem to think it is when you start digging into the details of what is being requested. I agree in principle that having filtering options for the layers panel would be quite nice, but this request as specified could lead to dangerous forms of confusion if not implemented very carefully.
-
Hi @florianr, welcome to the forums!
The shortcuts assigned to these by default are command+backtick and command+shift+backtick, but you can customize them under Preferences -> Keyboard Shortcuts.
The options are listed under the Miscellaneous category and are labeled "Switch to Next View" and "Switch to Previous View".
Note that the command+shift+bracket shortcuts are used for Arrange options by default, so you will also need to change those to avoid a conflict if you want this behavior. Given that command+bracket shortcuts are used for the other Arrange options, this is probably why the shifted versions were used there and not for tab switching. The Arrange options can be found under the Layer category.
-
2 hours ago, JGD said:
I accept your remark regarding the first feature request (which I will still defend on the grounds that, as per my stated MO, I'm trying to get as many team managers to realise just how serious the document model shortcomings are, but I respect your position so I will leave it at that), but not at all the one regarding variable fonts.
I think you are missing the point. The main problem is not that you are making a feature request, the problem is where you are making the request. It does not belong in this thread.
- Frozen Death Knight and JGD
-
2
-
28 minutes ago, Old Bruce said:
I have one bit of software which will travel with me should I choose to change platforms but it cost much much more than all three Affinity applications
I have quite a few more than that, but granted that most of those did indeed have higher price tags than the Affinity apps.
Examples:
- DxO PhotoLab
- On1 Photo RAW
- DaVinci Resolve, Fusion Studio
- Ableton Live
- Cubase
IDML: Unencoded Glyphs Not Handled Properly
in [ARCHIVE] Publisher beta on macOS threads
Posted
True, but I'm curious because I'm not 100% certain this means the font is invalid. Is it considered valid (in spite of being strange) for a program to use glyphs of a font which are not mapped to a valid code point?
I could understand that in the case of an embedded subset of a font in a PDF for example (I would think a specific glyph would need to be referenced anyway to indicate which should be rendered?) but with a "normal" font source not sure how a program would be expected to find the glyph with no code point being mapped...
InDesign does appear to have features for doing exactly that - identifying characters by glyph directly without going through the code point - so this might actually be technically valid:
https://helpx.adobe.com/indesign/using/glyphs-special-characters.html