bpedit

Thanks. I will have to go that route. My initial test with the multi-point lines was positive but I can't repeat it. I'm thinking it has something to do with the frequency of the Mesh nodes compared to the frequency of the line nodes. I need to export to SVG anyway for use in the CNC mill so I'll just leave the Mesh unconverted. The result of this method isn't exact, in my analysis, but likely close enough. Now for some testing on the machine. Thanks again.
Edit: The exported SVG of the unconverted Mesh is very close, maybe exact, to the appearance of the Mesh before Converting to Curves. This would seem a good hint as to how to remedy the issue. 

I downloaded and tried this in Designer 2.0.4 (Win10). You can click the images and check the results below:

SVG export seems to work fine: waterTst-original-scale.svg I checked the result Inkscape... I can open it or paste from Inkscape back into Designer. It doesn't appear to have flaws compared to the original warp group, but I haven't been looking at this as much as you might have already...

Thanks, disappointed to hear. I'm not sure if this file is the exact same as pictured above, I've gone through a few iterations. I tried it on desktop as well, maybe should have posted there.
waterTst.afdesign
One work around I can think of is to introduce nodes in the lines before applying the Warp. There appears to be no way to do that in AD except point-by-point. Maybe I'll try recreating the grid by duplicating a single line with the multiple points already extant.
Edit: When I remade my grid based on a line with multiple midpoints then applied the Mesh I got satisfactory results. Thanks for helping me realize I needed a work-around versus something I was doing wrong.

Here's the mesh I'm using on a bunch of parallel lines, attempting to simulate water for an engraving project:

 
When I exit Point mode I get this, looking good for my first trial anyway:

 
But when I Convert to Curves, I get this:

 
Ooooh, ick! What's going on? Strangely, if I Export the object, with the unconverted mesh intact, as an SVG, the results are closer to the desired result but not quite as desired.

Latest post on this subject, after some v2 assessment of the conditions of the grid/dimensioning accuracy and app UI feedback of Affinity Designer on both Mac and iPad.
It looks like Serif has addressed grid problems - Thank you! Grids on both platforms now agree with one another, and under Standard grid configurations, reflect the settings they are set to. One continuing incidence is that the settings under Standard are limited - and reach a point where input for grid size is not accepted. I couldn't find a threshold for this - it might have to do with resolution settings of the file.
For dimensioning limitations, it seems at least objects consistently reflect the size they have been set to. On both platforms. This is great news as a previous error across platforms made iPad version use nearly impossible. Great work, Serif!
So the layer size feedback is the last issue that needs to be fixed. And now this error extends to the Mac platform as well. Yah, it used to only occur on the iPad. But now a design doesn't reflect actual-sized layers ANYWHERE.  
I'll try to say this without repeating myself too much:
**If a user cannot visually confirm a layer's actual size, beyond one tenth of a unit (one number to the right of the decimal point), the app will continue to be largely useless to most designers needing decimal accuracy feedback.**
There is no work-around for this. Serif, please prioritize a fix.

V2 has not added this

I’m reposting this to make current an issue with the iPad version of Designer. I originally posted in 2018 and again in 2019 about the lack of real decimal unit accuracy when compared to the desktop version. I work in Designer a lot and am limited in what I can do on the iPad (my preferred Designer platform!) because this feature continues to be absent:
Decimal places in even small millimeter scales is possible in files created in the desktop Designer version. But move that file to the iPad, and while the placed units are correct, any attempt to view that accuracy (rounds to nearest whole number), or change the dimension to a decimal-level number - destroys the object’s dimensional accuracy. 
This really needs to be addressed by the dev team. There is no excuse that I can think of that would legitimize continued non-support of this basic-level (in many ways critical) feature. I’ll leave the forum members to weigh in on their experience, as well as hope for a response and plan from Serif.

You can, but only up to 400dpi. This surely has to be a bug as there is no logical reason for limiting. Post should be moved to Designer bug forum. 🤔

Thank you very much! I’m glad there’s a workaround, albeit unintuitive.
It’s another of those “is this really a serious product” details, though. Maybe you’re getting into less common territory above 2400 dpi, but to imply by UI design that 600 dpi was an unforeseen use case is frankly bizarre. What industry is “400” targeted at, as an upper default?
I know nobody has answers, I’m just upset that I’ve wasted so much of my day on this “upgrade” I paid for.

Hi Harry,
Currently, when we Export, we generate the image in the background and then move it to your specified location which was our reasoning for using Move instead of Save however as far as I'm aware we are currently looking at possibly changing this back to save to avoid confusion.
Thanks
C

I used a Kodak scanner, a SLIDE N SCAN, it reviewed a bit better than the Kodak you pictured.

It's fast at snapping the pic, the time is mostly in giving the slides a blast of air and feeding them into the scanner. The quality was mostly pretty good, some batches ("trips") not as good but that appeared, after examination with a scope, mostly a matter of the quality of the original. If you just have a few to do a professional job would probably be better, they pay more attention to cleaning and have better scanners, too expensive for a one-off use. This was adequate for my use. Remember to keep an eye out for specks lodging on the platen and use the included brush to remove them.

The quality loss argument when saving a JPG file with compression is severely overhyped and best left in the pro-photography world
Overwriting a 100% JPG file once, twice or even three times is unlikely to display any noticeable difference to the average human
I frequently download JPGs from the internet, work on them and export them with compression (85% quality) then later on I may have to tweak that exported JPG and export it again and I see no visible degradation in the image when doing this.
Don't believe the hype for general JPG usage - unless you are a professional photographer and need/want to squeeze every ounce of quality from an image that you can
 
Technically no.
If you open the JPG and export at 85% quality that is what you get
If you open and save the JPG it uses "100%" quality. Which in reality, due to the lossy nature of JPG files, is probably 99% or 98%
So, if you now export that file at 85% (via the batch job) you're probably looking at an overall quality of 84-83% of the original JPG file

But it's so small a drop versus just exporting the file (at 85%) it's hardly worth worrying about for the benefits of being able to batch process your files rather than doing an export for each one.
 
 

Interesting. Would this be the same, quality wise, as saving from the original opened file at the new resolution? I may test this.
Walt: I can't tell the difference between saving at 100% and saving at 95%, even at magnification. I would challenge others to point out the difference. Remember, I'm not working with high resolution digital originals but images of 35 mm slides taken with a 12 Mp scanner. The memory savings for my collection would be on the order of 25 GB.

The answer is no but what you could do is process all the JPGs using the Save button, then, when done, run a batch job (File > New Batch Job) to reprocess those JPGs with the compression (quality) value you want, overwriting the original JPGs

Thanks. I was aware of that feature in Export, you're correct that it seems to remember the setting (until closed anyway). My question was directed at trying to avoid the Export menu and just saving directly. But on further investigation it appears  that, at least,  the name is preserved as the default save name in Export. So this means three extra button pushes and two extra mouse moves per image compared to a simple save. Times 3,600 images!
Walt: I understand there's no inherent metadata of the saved quality, I was hoping for a way to set a default quality applicable to the Save function. Poor titling on my part, sorry.

Better yet, how about a choice, upon being notified of the conflict, of deleting the conflict without having to navigate to it. 

Completely agree. I’ve never used an app that I had to change the default setting for in order to see the UI properly. I hope Serif improves the default UI, but if not, I hope they add settings that enable users to make things more legible.

For me Line is selected and you can't tell plus the grayed out text is too gray and can't be controlled enough in dark mode. On the iPad its even worst in my opinion 
Please allow a user to control there interface will more contrast 
 

The "measurement tool" is a big tease. It seems like it's most of the way toward a far more useful dimensioning ability, one that remains in place.

This is partly due to some changes made to our export process and also some changes in iPadOS.  Technically speaking when you see the Move option thats because the file has already been created so from an iPadOS point of view, you are moving that file from a temp location to the one you've selected.  However, this is something the Dev are aware of and if it becomes possible to change this in a future build, they will do so  

You can edit a placed image nondestructively, and keep its original resolution
to erase, add a mask to the file, and erase from mask to paint over, add a pixel  layer above the image and paint there. this will use the 96dpi from your document. Resizing these layers should be avoided.
The best approach would be to open the image in native resolution in a separate Designer document,
and add pixel layers and mask there. then place the designer file into your original document. This keeps the original high dpi, and allows resizing at any time.

The "measurement tool" is a big tease. It seems like it's most of the way toward a far more useful dimensioning ability, one that remains in place.

Get rid of the Stroke Width slider, along the screen's left, when in Point mode. This is taking up valuable real estate, we all know where to find it the few times (never for me) one may want to use it editing points.

It would be very useful if the arrows created by the measurement tool could optionally be converted to objects on a new layer. Ditto for the area tool.