fde101

The desktop versions allow up to 6 digits of precision. I suspect it would be problematic due to the display size limitations on the iPad and the slight differences in the way things are organized to support that many, so while supporting 2 or maybe even 3 would not be an issue, they may be hesitant to provide the option if not supporting all 6 digits. Personally I don't think rounding to 1 digit above the slider is much of a problem, but I am much more bothered by the fact that if I tap on the value to open the editor, it still rounds to 1 digit, even though it is a direct typing editor for just that one value and there is no reason why it should be constrained in the amount of available space. I would like to think the editor should always show all available digits when it is opened.

In that case, I would like to suggest including the bug numbers that are attached to the forum threads in the list of changes in the future (ex. there is a thread which appears to be the white balance issue which was tagged "AFP-5803" in the bug reporting section) to make it easier for users to match the list in these announcements back to the relevant threads, since it is not always as obvious as that one.

As @Pyanepsion shows above, you can change the displayed precision from the user interface preferences on the desktop versions - but note that this only impacts the display of the point size. The size actually does support more digits of precision, but the value gets rounded off for display after you enter it. If you type in 0.25, even with only one digit displaying, it will round off after you enter it (if the default precision of 1 digit is selected) but will still be stored as 0.25 behind the scenes. On the iPad version, there is unfortunately no way to adjust the display precision for these values, so you can't really see past the first digit - even when editing the value after it is entered - but you can enter more precise values and they do stick. To type in a more precise value, tap on the displayed line width value for an interface to enter the value you want. To test this, I created a new document in Designer on my iPad and created three lines, manually entering the line width of each. I set one to 0.2, one to 0.25 and one to 0.3 points. Both the 0.25 and the 0.3 point widths display as 0.3 on the iPad, even in the editor if I tap on them to edit the value I had entered. When I transfer the document to my Mac and set the display precision to 2 digits, I can easily see that they are actually 0.2, 0.25 and 0.3 points in width, as they were entered.

\< is a GNU extension which is not supported by most regular expression engines; I wonder if they changed engines or grammars between the two versions? I don't have any Czech text to test on, but try using either \b or [[:<:]] instead of \< to see if that makes a difference? More details on these differences are documented here: https://www.regular-expressions.info/wordboundaries.html

I may be missing something, but have you considered using a grid instead?

Yes, I think the simplest way to meet this desire to make it easier to identify corrected bugs would be if Serif would also list those tags in the change list they provide with each release - instead of "fixed bug which was..." they could list "AFD-...: fixed bug which was..." and give us something to match up to the various threads discussing these concerns.

Hi @Harukael, welcome to the forums! Separate requests should really be in separate threads, and there are already numerous threads discussing requests for both vertical and right-to-left language support, so I'm otherwise going to ignore that second request for now... It would probably make more sense for Serif to develop an Android version than a dedicated ChromeOS version; my understanding is that many ChromeOS systems can run Android apps, and if they put it in both Google Play and the Amazon App Store, they could cover a wide range of devices, including evidently Windows 11 at some point in the near future, allowing them to eventually discontinue the dedicated Windows version, freeing up the resources they need to develop for the additional (Android) platform.

It is not just our own time we are wasting. Having multiple threads on the same topic splits the conversation on the topic across multiple places. This leads to discussions being all over the place and people trying to find ideas (such as developers looking into what people want implemented) need to go through a tangled mess to see what was requested. If there is one thread on a topic and a developer looking for clues on what people want find it they can more easily scan through the whole thing. If there are 20 threads on the same basic subject and a developer is looking for information, particularly since most of what those threads contain is likely to be duplicated, it would waste far more of the developer's time to read them all and try to detangle the details contained inside, and they could be using that time to develop the feature. Thus sensible ideas that might have otherwise made it into the product are far more likely to get lost in the noise when there are many threads on the same subject, or when people keep endlessly duplicating the same information and requests because they fail to take note of what was already said.

Serif has a public email address for users to contact them with along with a presence on various [anti]social media platforms (ex Twitter and Facebook). While the web site does push users to use the forums for reporting bugs, I suspect that Serif is likely consolidating bug reports from multiple sources and including them in their internal tracking system.

Apologies, I was looking at this incorrectly. No, you can still change the color of the column guides and of the margin guides, but still not of the manual ones.

Which guides do you mean? You can set the manual guides (that you drag out from the rulers) as well as the page margin guides from View -> Guides... I believe you can do that in v1 also though the menu option may have been in a different place.

I remain quite puzzled over the number of users trying to use what is clearly intended as an illustration/artistry program as a "lightweight CAD" program, when there are actual, real, intentional CAD programs available which are inexpensive or even completely free, which are intended for the function and much more suitable for it. Take a look at LibreCAD for example: https://librecad.org Or possibly FreeCAD: https://www.freecadweb.org/?lang=en FreeCAD works a bit differently from other CAD software in the way that the models are built up, which may make it easier to construct some of the shapes you seem to be working with, but it would require a bit more of an adjustment in the way that you interact with the software.

This is true of ECMAScript / JavaScript as well. I definitely would have preferred Lua over JavaScript for practically *any* software, but this particular feature is not a differentiator between the two languages.

Either that or it misprinted someone's medical diagnosis and whoever retrieved it from the printer wasn't paying enough attention...

I wish they had gone with Lua - that would have been at least tolerable. Instead they picked the second worst of the common scripting languages: Suggest looking at Lazarus instead to make it more accessible for others if you have any plan on sharing: https://www.lazarus-ide.org Also suggest moving any further discussion to the thread I linked above to keep it together in one place. No need to proliferate lots of threads requesting the same thing.