Bug #48365 filed six weeks ago. No sign of acknowledgement.

users
#1

Hello;

On April 6th I filed bug #48365 for Libre Office Draw ["Exporting as an EPS file results in an incorrectly scaled image (appears larger than original)"]. It is now six weeks later and there is no sign that anyone has acknowledged the bug report, much less looked into it. Perhaps this is the way it works, with long response times. I would appreciate any comments. If I have incorrectly filed the report, I will be happy to modify it. If it just takes time, I would appreciate knowing.

Here is the link:

https://bugs.freedesktop.org/show_bug.cgi?id=48365

Thank you very much for your help.

John Hardy

#2

Hi :slight_smile:
It does just take time but it's not a que.  It just depends on it catching the eye of the devs.  It might be worth askingt he devs list what they think.
Apols and regards from
Tom :slight_smile:

#3

Tom;

It does just take time but it's not a que. It just depends on it catching the eye of the devs. It might be worth askingt he devs list what they think.
Apols and regards

Where might I find the devs list (and how to subscribe)? Thanks very much.

John

#4

Before doing this, is there anyway to upgrade to the latest version of LibreOffice? I think the answer you will get on the dev list will be to upgrade to the latest supported version.

This will also allow us to test your bug report, confirm whether is happens on the latest version.

As far as the length of time goes, the triage of bugs does take time depending on the severity of bugs submitted. Also, most of the devs are volunteers and it does take some time for someone to either be assigned to it or for someone to pick it up.

The more people test it with descriptive results the quicker and easier it will be to fix or at the very least find a temporary workaround.

Cheers,

Marc

#5

Marc;

Before doing this, is there anyway to upgrade to the latest version of LibreOffice?

I will do that. I downloaded version 3.5.3, but I need to close a few windows before I can install it. Looks like 3.5.4 is coming along.

As far as the length of time goes, the triage of bugs does take time depending on the severity of bugs submitted. Also, most of the devs are volunteers and it does take some time for someone to either be assigned to it or for someone to pick it up.

Thanks for giving some perspective to the time line. The bug was assigned to "libreoffice-bugs@lists.freedesktop.org", but I have no idea what that means, or if anyone has actually even seen the bug.

I will update the bug report as soon as I install V3.5.3 or 3.5.4 and try things. Thanks.

John

#6

Hi John,

Marc;

Before doing this, is there anyway to upgrade to the latest version of
LibreOffice?

I will do that. I downloaded version 3.5.3, but I need to close a few
windows before I can install it. Looks like 3.5.4 is coming along.

As far as the length of time goes, the triage of bugs does take time
depending on the severity of bugs submitted. Also, most of the devs
are volunteers and it does take some time for someone to either be
assigned to it or for someone to pick it up.

Thanks for giving some perspective to the time line. The bug was
assigned to "libreoffice-bugs@lists.freedesktop.org", but I have no idea
what that means, or if anyone has actually even seen the bug.

I will update the bug report as soon as I install V3.5.3 or 3.5.4 and
try things. Thanks.

John

Thanks!

BTW ... I downloaded your graphic. I am not all that familiar with Draw, how do I go about finding out the dimensions of your drawing so that I can compare its size to the EPS version?

Cheers,

Marc

#7

Marc;

BTW ... I downloaded your graphic. I am not all that familiar with Draw, how do I go about finding out the dimensions of your drawing so that I can compare its size to the EPS version?

The reference file file should look properly scaled when viewed in Draw. You can see it correctly scaled by visiting the product page and looking at the picture of the correctly scaled image as printed on the product:

http://www.johnhardyco.com/990OpAmpDetails.html

It is when you "Export" the file using the "EPS" file-type and view the EPS file with GIMP (and other viewers) that you can see that things are scaled incorrectly. The first clue when viewing the EPS file: Look at the model number, "990c". The "c" is overlapping the "0". It is not supposed to overlap. I created two separate text boxes, one for the "990" and one for the "c", so that I could control the spacing between the main part number ("990") and the suffix ("c"), as well as use different sizes for the text in each box. Somehow during the incorrect scaling everything gets about 10% bigger and the "c" overlaps the "0" as a result.

If you take the reference file and "Export as PDF", it should be correctly scaled when viewed as a PDF (the "c" does not overlap the "0"). So something is different between "Export as PDF", and "Export" with the "EPS" file-type chosen. Yet both methods work OK in OpenOffice 3.3.

Let me know if you need further information or example files. But comparing the results of ["Export as PDF"] and ["Export" with the "EPS" file-type] should reveal that the EPS approach is not scaling things correctly.

Thank you.

John

#8

Marc;

By the way, if it is allowed to attach images here, I can provide an image of two of the aluminum potting shells side-by-side, one having a correctly scaled image, the other incorrectly scaled.

John

#9

You can send me the attachment directly to my email address.

Cheers,

Marc

#10

Hi John

Marc;

BTW ... I downloaded your graphic. I am not all that familiar with
Draw, how do I go about finding out the dimensions of your drawing so
that I can compare its size to the EPS version?

The reference file file should look properly scaled when viewed in Draw.
You can see it correctly scaled by visiting the product page and looking
at the picture of the correctly scaled image as printed on the product:

http://www.johnhardyco.com/990OpAmpDetails.html

It is when you "Export" the file using the "EPS" file-type and view the
EPS file with GIMP (and other viewers) that you can see that things are
scaled incorrectly. The first clue when viewing the EPS file: Look at
the model number, "990c". The "c" is overlapping the "0". It is not
supposed to overlap. I created two separate text boxes, one for the
"990" and one for the "c", so that I could control the spacing between
the main part number ("990") and the suffix ("c"), as well as use
different sizes for the text in each box. Somehow during the incorrect
scaling everything gets about 10% bigger and the "c" overlaps the "0" as
a result.

Is it just me or does your "C" overlap your "0" on your attachment .odg file on the bug list? You may need to upload the file again.

John

Cheers,

Marc

#11

Marc;

Is it just me or does your "C" overlap your "0" on your attachment .odg file on the bug list? You may need to upload the file again.

I just uploaded my file directly from the bug page into LibreOffice Draw 3.5.2.2. It appears correctly on my computer. There is white space between the "c" and the "0". There is greater space between the digits of "990". When the file is Exported using the "EPS" file-type, the resulting image shows an overlap between the "c" and the "0", and everything is bigger.

What version of LibreOffice are you using to view the file? I just realized that the file is now in a "read-only" state, but you should be able to Export as PDF, and also Export using the EPS file-type.

Thanks.

John

#12

Marc;

Is it just me or does your "C" overlap your "0" on your attachment
.odg file on the bug list? You may need to upload the file again.

I just uploaded my file directly from the bug page into LibreOffice Draw
3.5.2.2. It appears correctly on my computer. There is white space
between the "c" and the "0". There is greater space between the digits
of "990". When the file is Exported using the "EPS" file-type, the
resulting image shows an overlap between the "c" and the "0", and
everything is bigger.

What version of LibreOffice are you using to view the file? I just
realized that the file is now in a "read-only" state, but you should be
able to Export as PDF, and also Export using the EPS file-type.

I'm using 3.5.3.2. I guess the file is read differently with the latest version. Maybe someone could verify this. If this is the case, maybe by re-arranging the "C" in the .odg and then exporting to EPS, just maybe, the EPS version will have been fixed and both will be identical. OR maybe there is just a reason why the EPS is not exported properly, Maybe re-doing the graphic from scratch may fix it?

Here is the screen capture that I get: http://www.parentreprise.com/images/LibreOffice/990C-Graphics2012-03-19.odg.png

Thanks.

John

Cheers,

Marc

#13

Hi :slight_smile:
You can always upload a file to Nabble. Once you find your thread in Nabble
and click on reply to one of the messages then just click on the "More"
button. "Upload file" is the top option. That will generate a link in the
message.

In this particular case it's probably better to upload the file to the
bug-report and then give this list a link to that, which is pretty much what
you have already done anyway :slight_smile: It is good to have the actual file rather
than just pictures of it. The pictures were a good idea tho. It lets
people know what you are seeing on your system which would help if they
can't repeat the same problem on their machine.
Regards from
Tom :slight_smile:

#14

Hi :slight_smile:
If you still want to search out the devs list then this link might help
http://www.libreoffice.org/get-help/mailing-lists/
iirc might be worth looking for too (whatever that is!)
Regards from
Tom :slight_smile:

#15

Marc;

Here is the screen capture that I get: http://www.parentreprise.com/images/LibreOffice/990C-Graphics2012-03-19.odg.png

Your captured image is (obviously) not even close to what it is supposed to look like. The "990c" text appears to be a completely different font in your screen capture. HOWEVER: I just loaded the file directly from the bug report page into Draw 3.5.2.2 again. The file was in read-only mode, so I Saved it to my hard drive and reopened it to be able to see what the actual fonts are. Observations:

1. The "990c" text looked OK. When I highlight the "990c" text, the font is identified by Draw as "Square 721" with the Bold attribute turned on. This is an OpenType font, and the Bold attribute should not be on. When I turn the Bold attribute off, the font changes completely, looking much less square, much more rounded, similar to the font in your screen capture. It looks like a slightly bolder version of the font that is used for the text under the "990c" text, specifically the "U.S. PATENT #4,287,479" text (the "9" is the best clue). That text is the "Formata" font. There is a bold version of Formata, and the "990c" text from your image is bolder than the regular Formata, but not as bold as the actual Bold version. But almost identical in form. I wonder if some metrics were mixed up.

2. The font name "Square 721" that is displayed when I highlight the existing "990c" text isn't the full name of the font. If I add new text, the font list has "Square 721 Condensed" as the name of the font, and the Bold attribute is NOT turned on. It does not need to be turned on. In fact, turning the Bold attribute ON has no effect on the appearance of the font in this case. If I add new text using "Square 721 Condensed", then go back to that text later to verify, it is still described as "Square 721 Condensed". I don't know if the shorter name of the font in the example drawing matters. It may just be a shorthand way for Draw to identify the font by name. Or it may be an indication of other issues with the handling of fonts.

Some of the small type appears to be a different font than it should be, particularly the word "OUT" (Output). It is supposed to be much narrower in appearance, using the "Humanist 521 condensed" font. Same effect with the "-V" and "+V" text (the "+V" text is partially covered by the mangled "990c" text in your image.

I've done some quick experiments with a simple new drawing created in Draw 3.5.2.2. I'm not sure, but things seem to be handled OK when Exported as an EPS file. On the other hand, GIMP printed a blank page. So, I will look into it more tomorrow. Lots of variables. There is also the fact that you are using a slightly later version of Draw (3.5.3.2), so it is hard to tell where the errors are being introduced.

Thanks you very much for your help. More information later.

John

#16

Hi :slight_smile:
Re-creating a fresh new image using the newer branch was brilliant.  Sometimes older documents that have "been around the block a few times" get a lot of inexplicable weirdnesses.  Sending your new version directly to the original poster might be enough to solve the problem.  Even if it doesn't then it would be a useful note for the bug-report so sending it is a win-win. 
Regards from
Tom :slight_smile:

#17

Tom;

Re-creating a fresh new image using the newer branch was brilliant. Sometimes older documents that have "been around the block a few times" get a lot of inexplicable weirdnesses.

I have only made a few drawings, and fairly simple ones at that. So starting over is not hard. However, it was a jolt to receive a batch of printed potting shells with the image scaled incorrectly. Fortunately, not enough to be unusable. I hope there aren't other users out there that have many drawings that will need to be done over.

OpenOffice had a problem (bug #114901) a couple of years ago where it started mishandling Adobe Type 1 fonts. The simpler solution was to convert them to TrueType fonts. I can't even find that bug now. And so it goes.

Even though Draw is a fairly simple program, it has the ability to expand or condense the spacing between characters, and pair kerning. I condensed the spacing with the "990" part of the drawing for a tighter look. DesignCAD 3D Max V21 cannot do that.

I will verify future drawings before submitting them for production.

John

#18

Hi :slight_smile:
Hmm, i hadn't thought about that.  I guess Draw is probably treated differently from word-processing.

Typically office workers will open some old document and then just delete everything visible and then start writing a new document in there.  I have found documents with non-printing characters and even empty tables and stuff.  One had been created on a Mac using something other than MS Office.  Most have a lot of 'personal' info such as name and company address that are clearly nothing to do with my workplace.  It wouldn't surprise me to find 'new' documents that could be traced back to the documents origins in Win95.

I kinda imagined people would similarly open an old word-processed document and then "Save As.." to get it as a odg and then delete a few things and add drawings.  I guess that with Draw people might do the hugely complicated
File - New
instead.

Regards from
Tom :slight_smile: