LiveCode Forums.

Hi all

I'm using the following command:

put 300 into theMetadataA["density"]
export snapshot from card "x" at size 1536,2048 with metadata theMetadataA to file tPNGName as PNG

My card size is 1024x768, so this size is effectively doubling that so that the quality of the image is higher. The card contains basic line objects, set images and text fields, all of which come out correctly when running the command on my Mac test environment.

Sample of the output: When I attempt to run the same command on Linux, it seems to incorrectly enlarge the text fields but nothing else: Any idea?

I'm not sure why it would do that on Linux but I notice the export size dimensions are reversed from the original dimensions. Maybe the Linux engine is getting confused.

Glad you caught that, I didn't spot it 3x through

It creates an image which is 1536 width x 2048 height. The dimensions are correct when inspecting the image on Mac (if I trigger it either from Mac or Linux), but it does not convert the text size correctly.

I might not have been clear. You said the card was 1024x768, which is wider than it is tall. The script directs the export to be 1536 x 2048, which is taller than it is wide. In other words, you're changing the ratio of width to height and I wonder if that's causing an issue.

An exact export at double size would be 2048 x 1536.

Sorry, no, the reference to 1024x768 was just due to the way of normally pronouncing that resolution.

The stack is 768 width by 1024 height, as it is meant to output in portrait on an A4 page. This exact code outputs an image perfectly on Mac, but not on Linux. If I use open printing to pdf on Linux, I can correctly get the dimensions for an A4 PDF which doesn't have scaling/blurring issues, but I need to use a simpler file like a PNG which is not working - if I leave the PNG 768x1024 it is not a high enough quality when printed on A4.

In that case it sounds like a bug. All platforms should work the same way, so it's a candidate for a bug report.

I can confirm that either vertical and horizontal scaling (or the combination of the two) mangles the exporting of text on linux (text in fields, text in buttons...). Images do scale properly.

jacque wrote: Maybe the Linux engine is getting confused.

What a lovely wording! Hopefully it will regain its health ...

[-hh] wrote: ↑

Thu Jan 25, 2018 6:44 pm

jacque wrote: Maybe the Linux engine is getting confused.

What a lovely wording! Hopefully it will regain its health ...

Unlikely unless someone reports it. Did I miss a bug report number from an earlier post? If not, whomever report this please note the bug ID here so we can follow it. Thanks.

As you insist on a report:

Bug 20913 - The Linux engine is getting confused
http://quality.livecode.com/show_bug.cgi?id=20913

[-hh] wrote: ↑

Thu Jan 25, 2018 11:07 pm

As you insist on a report:

Bug 20913 - The Linux engine is getting confused
http://quality.livecode.com/show_bug.cgi?id=20913

Amazing how a satirical bug post gets replied to before a legitimate one: http://quality.livecode.com/show_bug.cgi?id=20902
So I shouldn't bother reporting issues for older versions then?

Let's start again.

Recompiled the same stack on 8.1.8 stable, and now no text shows when using the following:

put 300 into theMetadataA["density"]
export snapshot from card "rxcopy" at size 1536,2048 with metadata theMetadataA to file tPNGName as PNG

New bug report: http://quality.livecode.com/show_bug.cgi?id=20914

Hi all,

Amazing how a satirical bug post gets replied to before a legitimate one: http://quality.livecode.com/show_bug.cgi?id=20902

Hehe, well, it was not an "official" reply (this is why I did not change the status to CONFIRMED in Hermann's report), it was more of a comment by myself as a LC user, not a LC staff.

I had already seen your report, but did not test it yet, so I had in mind that something is wrong with export snapshot / text rendering on Linux. Then I saw another report (Hermann's), so since more that one people mention the same problem, it is highly likely that it is a bug. But rather than testing the original report, I chose to add a (user) comment to the "satirical" one, and officially test the original report the day after

So I shouldn't bother reporting issues for older versions then?

We ask our users to report any issues in any LC version they use. Then we check if the issue is fixed in newer versions we maintain (LC 8 and 9), and if not, we add it to the TOFIX list, otherwise we we close the report.

Hope this helps,
Panos
--

LiveCode_Panos wrote: ↑

Fri Jan 26, 2018 12:14 pm

So I shouldn't bother reporting issues for older versions then?

We ask our users to report any issues in any LC version they use. Then we check if the issue is fixed in newer versions we maintain (LC 8 and 9), and if not, we add it to the TOFIX list, otherwise we we close the report.

Hope this helps,
Panos
--

That is helpful (to me, anyway). I had just figured the versions I use are so old any bug reports from them would be useless.

While I understand that they are useless for those versions, now I will report any I come across, provided I can figure out if they have already been reported or not. I sure wish the bug reporting itself didn't require making another login/password, though, for instance if it were based on your account login that would be nice.

I don't think a single-sign-on approach is going to work. I have different logons for this forum, for the listservs, for the LC website, for on-rev, for whatever-the-stack-sharing-site-is-called-these-days, for github, and for bugzilla. These different software packages all want to do things their way and don't play well together.