[sw-issues] [Issue 58919] Blank Pages in Mail Merge
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=58919 --- Additional comments from crx...@openoffice.org Fri Sep 24 21:01:40 + 2010 --- It has been two years since my last comment on this issue, reported 5 years ago... Yes, it is still a big problem for my users. It is a frequent drain of support time in my department trying to explain to users and help work-around the broken behavior of OO adding blank pages in merges. If the developers are unwilling to change the UI, can't we at least have a system-level flag/setting somewhere to turn off the blank pages generation? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 --- Additional comments from crx...@openoffice.org Thu Aug 5 03:40:05 + 2010 --- Only 60? I have over 150 users and we have been waiting over a year. I had to completely halt the rollout of OpenOffice 3.0 because this problem was too severe for us. Waited through 3.0, 3.1, then 3.2. I am praying it is in 3.3 (I think it is). I, too, was hoping there would have at least been a back door fix or something until the new print system stuff was rolled out. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 4499] Export to bitmap file has f ixed DPI (resolution)
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=4499 --- Additional comments from crx...@openoffice.org Thu Jun 17 21:41:11 + 2010 --- @sj: sample dialog looks great! It is exactly what I had in mind! The memory usage and output file size is an excellent bonus. I have not tried the extension so I have to ask: I assume that the aspect ratio is locked so if you change the width it will recalculate the height or vice-versa. And the resolution (ppi/dpi) is relative to the width/height, so if you change the width/height, it will update the ppi, or if you change the ppi it will update the width/height. (Correct me if I am wrong) Hopefully the coming changes will also remove the rather low fixed maximum resolution. Last I checked, the maximum resolution you can export in Draw is 2250x2048 pixels, which is just not large enough if you need a high-resolution raster export of a large vector diagram. I didn't see any followup on that aspect from my posting on Nov 26, 2007... - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 111688] Snap to grid drift
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=111688 --- Additional comments from crx...@openoffice.org Thu May 27 21:33:40 + 2010 --- @jes Well, I am glad it is a real issue and I am not losing my mind :) Fixing it so it doesn't continue to happen would be great (if possible). I still wonder if I should create a new enhancement issue with the request for a new feature that will fix existing documents in which the objects are no longer snapped to the grid. I was thinking Modify- Arrange- Snap points to grid This option will move every point in every selected object so that they land on the nearest currently defined grid point - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 111688] Snap to grid drift
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=111688 --- Additional comments from crx...@openoffice.org Tue May 25 13:09:42 + 2010 --- Created an attachment (id=69624) Example of all objects off the grid slightly - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 111688] Snap to grid drift
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=111688 --- Additional comments from crx...@openoffice.org Tue May 25 13:10:34 + 2010 --- @wg, I have attached a sample document for which every object on the page is no longer snapped to the grid. If you zoom in to max zoom, select a horizontal line, and move one end point, you will see that it moves ever so slightly to re-snap that point to the grid. Unfortunately, I don't know how the document became that way. I have several saved revisions and if I go back far enough, it seems to have happened when all the objects were moved down on the page. But every object on the page was landing on a grid point, the grid never changed, and they would have been moved while the snap to grid was in effect, so it should not have moved off the grid. More unfortunately, I didn't notice that it moved off the grid and spent a hundred hours adding many more layers and objects. And now it is impossible to get all the objects back onto the grid :( I don't know what you mean by mark the problem, hopefully I have covered your request. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 111688] Snap to grid drift
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=111688 --- Additional comments from crx...@openoffice.org Wed May 19 21:29:16 + 2010 --- I am working with English units, not metric and have never changed it. I also never changed the margins and never touched the origin. I showed the issue to a co-worker today, who said oh, yes, it has done that to me also in drawings, but the shift was so small I thought I did something wrong. In this particular (last) case, the grid was shifted up (vertically) a few pixels. It stayed the same horizontally. I could attach a sample drawing in which the shift has occurred but I am not sure that would help. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 111688] Snap to grid drift
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=111688 Issue #|111688 Summary|Snap to grid drift Component|Drawing Version|OOo 3.2 Platform|All URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|editing Assigned to|graphicsneedsconfirm Reported by|crxssi --- Additional comments from crx...@openoffice.org Tue May 18 23:28:08 + 2010 --- I have noticed this over the years and have never reported it as a bug until now. I can use the snap-to-grid option, then create a complex drawing with thousands of objects. Things progress over days fine, saving, loading, editing, etc. But at some point, the grid will change position ever so slightly and throw off all my objects. I never touched the grid settings nor origin. If, for example, I had a perfect square, drawn with 4 lines, so some later load, the grid will shift a pixel or two and then if I move one of the corners and place it back to where it was, the lines are no longer straight and the square is no longer a perfect square and it is impossible to fix. I have seen this happen multiple times, across multiple versions of Draw. I have no explanation. More frustrating is that it is then impossible to ever fix the drawing back to the grid again. And if you have many thousands of objects, like a blueprint or floor plan, it causes a big mess. In addition to a fix for this bug, it would be nice to have an enhancement tool that will allow the user to select certain objects or all objects, then perform a correction that will snap every point in those objects to each nearest grid point. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 110895] Add master layer tab cont roller
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=110895 Issue #|110895 Summary|Add master layer tab controller Component|Drawing Version|OOo 3.2 Platform|Unknown URL| OS/Version|All Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|ENHANCEMENT Priority|P3 Subcomponent|ui Assigned to|graphicsneedsconfirm Reported by|crxssi --- Additional comments from crx...@openoffice.org Thu Apr 15 03:03:40 + 2010 --- When managing/editing a complex Draw document that has lots of layers/tabs, it can be very difficult to deal with the all the attributes. One thing that would improve the situation would be to have a master tab that will control all the other tabs at the same time with: Set visible on all tabs Set printable on all tabs Set locked on all tabs Along with: Unset visible on all tabs Unset printable on all tabs Unset locked on all tabs Example- you have 15 tabs and just want to view what is on only one of them. Choose master tab, choose unset visible on all tabs, then select the tab you want and make that single one visible. Two 2 instead of 14. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 110896] Reorder/move layer tabs
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=110896 Issue #|110896 Summary|Reorder/move layer tabs Component|Drawing Version|OOo 3.2 Platform|All URL| OS/Version|All Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|ENHANCEMENT Priority|P3 Subcomponent|ui Assigned to|graphicsneedsconfirm Reported by|crxssi --- Additional comments from crx...@openoffice.org Thu Apr 15 03:09:03 + 2010 --- It is not currently possible to move or re-order the layer tabs in Draw. It would be nice to have this feature. One should be able to drag the tab to a new location, like you can in Calc. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 108718] WMF vector objects vertic ally flipped or 180 rotated appear wrong
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=108718 --- Additional comments from crx...@openoffice.org Thu Jan 28 23:38:11 + 2010 --- Looks like Issue 102175, fixed as of DEV300_m57. Agreed. Yeesh Not the first time I can spend a lot of time searching through bugs trying to find a duplicate before spending hours created a nice bug report with lots of tests and attachments and things only to find there is a duplicate, afterall. But this is the first time I went through all that AND it was fixed before my posting was ever made :) Oh well! Congrats + thanks - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 108718] WMF vector objects vertic ally flipped or 180 rotated appear wrong
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=108718 Issue #|108718 Summary|WMF vector objects vertically flipped or 180 rotated a |ppear wrong Component|Drawing Version|OOo 3.1.1 Platform|Unknown URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P2 Subcomponent|viewing Assigned to|graphicsneedsconfirm Reported by|crxssi --- Additional comments from crx...@openoffice.org Wed Jan 27 19:06:52 + 2010 --- Insert a vector-based wmf object into Draw. It is visually impossible to vertically flip the object, it will flip it horizontally instead. It is also impossible to rotate the object 180 degrees- it will just appear to not rotate it at all as soon as you hit 180 degrees. Plus, if you try to rotate objects 90 or 270 degrees (or anywhere in between), they often get horribly distorted in ways that are hard to describe here in words. But here is the even worse part- it *IS* rotating and flipping the object correctly, it is just not displaying it correctly. If you save the document then open it in an older version of OpenOffice (2.3), it looks perfect. We noticed this behavior starting in 3.1.0, although we did not test in 3.0. It worked fine in 2.3. I will attach a sample ODG file to illustrate the problem, along with two screen shots showing what the document appears on the screen when viewed from 3.1.1 and 2.3.0. This is a horrible bug. It affects all the clipart and logos we use on a regular basis. And I searched and could not find any other reports. Perhaps I was using the wrong terms. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 108718] WMF vector objects vertic ally flipped or 180 rotated appear wrong
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=108718 --- Additional comments from crx...@openoffice.org Wed Jan 27 19:08:08 + 2010 --- Created an attachment (id=67442) document showing rotation display error in 3.X - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 108718] WMF vector objects vertic ally flipped or 180 rotated appear wrong
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=108718 --- Additional comments from crx...@openoffice.org Wed Jan 27 19:09:06 + 2010 --- Created an attachment (id=67443) Screen shot of correct behavior in 2.3.0 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 108718] WMF vector objects vertic ally flipped or 180 rotated appear wrong
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=108718 --- Additional comments from crx...@openoffice.org Wed Jan 27 19:09:33 + 2010 --- Created an attachment (id=67444) Screen shot of broken behavior in 3.1.1 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 108718] WMF vector objects vertic ally flipped or 180 rotated appear wrong
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=108718 --- Additional comments from crx...@openoffice.org Wed Jan 27 19:18:30 + 2010 --- Also note that when you print the incorrectly displayed document in 3.1.X, it prints even WORSE (different than displayed and wrong in a different way)! I have attached a scan of a printout from 3.1.1. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 108718] WMF vector objects vertic ally flipped or 180 rotated appear wrong
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=108718 --- Additional comments from crx...@openoffice.org Wed Jan 27 19:20:25 + 2010 --- Created an attachment (id=67445) Scan of printout from 3.1.1 showing even worse behavior - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 108718] WMF vector objects vertic ally flipped or 180 rotated appear wrong
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=108718 User crxssi changed the following: What|Old value |New value Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Additional comments from crx...@openoffice.org Wed Jan 27 20:09:47 + 2010 --- Well, I just tested OpenOffice 3.2.0 RC4 and it is completely fixed. So I guess this was a known issue. Still, it is good that there is a comprehensive record of the issue for other people trying to figure out what is going on. I am closing the issue as Fixed - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 --- Additional comments from crx...@openoffice.org Thu Sep 3 11:57:52 + 2009 --- I am guessing the change in target is bad news and we won't be able to upgrade from OpenOffice 2.X for another year? :( - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 --- Additional comments from crx...@openoffice.org Fri Sep 4 03:01:05 + 2009 --- Well, I don't want untested or unstable code in a mainline release either. But I was at least hoping the proposed office/share/registry/data/org/openoffice/VCL.xcu setting would be available quickly. Since that doesn't affect the UI, it should be a safe place to start, wouldn't it? As for upgrading- the problem is so serious, there is no way I can roll out 3.X to my users if I cannot disable the collate option (or at least default it to no). - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 --- Additional comments from crx...@openoffice.org Fri Jul 17 02:16:27 + 2009 --- @pl: that is great news, indeed. From what I am reading of what you programmed, that is exactly the type of behavior that will allow the collate problems to be fixed for *everyone*. I (and my users) can't thank you enough. Hopefully this can be made into documentation somewhere too, since others are bound to hit the same problem. Is there any expectation this will make it into release sooner than 3.2? As for the N-Up- I talked about that with some people at work, and they are quite excited about that option. Would be nice for preview printing and archival of large documents to paper. We all still think it would be best if that were also not made a persistent/remembered setting, although it would be far, far, far less damaging than the issue with collate or number of copies. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sc-issues] [Issue 10933] Data sorting by using more than 3 items (columns)
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=10933 --- Additional comments from crx...@openoffice.org Tue Jun 23 22:21:32 + 2009 --- I have to agree that sorting by more than 3 criteria is important. My users ask fairly frequently why Calc can only sort by 3, and I have to say that I don't know why there is that arbitrary limitation. Using a database is beyond their skill sets. Can't it be changed to allow pretty much unlimited sort keys? Or at least bump it up to 4 or 5? It doesn't seem like bumping it up a few would be too difficult, plus in 3.X the dialog box is already big enough to easily hold 4 and the sort function doesn't seem to affect or play on any other code in Calc... - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org For additional commands, e-mail: issues-h...@sc.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sc-issues] [Issue 10933] Data sorting by using more than 3 items (columns)
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=10933 --- Additional comments from crx...@openoffice.org Tue Jun 23 22:45:35 + 2009 --- I did want to point out that although you can't perform ONE sort operation by more than three criteria in Calc, you *can* sort by more than three criteria, it requires multiple sort operations with this workaround: *Example- sorting by 4 criteria: First sort your data only your LEAST important (4th) criteria. Then sort the data again, by the first three criteria. *Example- sorting by 5 criteria: Sort first by the 4th and 5th criteria. Then sort again by 1st through 3rd criteria. This works, although many users just won't know this method, and/or won't find it convenient or intuitive. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org For additional commands, e-mail: issues-h...@sc.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 --- Additional comments from crx...@openoffice.org Mon Jun 8 11:17:26 + 2009 --- Yikes! You don't want persistence on number of copies! I can see that being a big problem! User opens document, prints 100 copies. Closes document. Next day, they open some other document and then print it. Users will not think about number of copies, because they assume 1 (like all other applications)... but they get 100! Even worse- next day, user opens another document, then prints using the quick-print icon. They get 100! If there is one thing I know really well, it is user behavior. Trust me, you don't copies to be persistent. Persistence with collate makes sense, because that is a decision that is likely to never change. But copies should always default to 1. It is much, much safer. BTW, Print-Options and Print-Properties are things stored in the document itself (I just checked); which makes sense. So there are only two other options- collate and copies. I don't see N-up or anything else... - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 --- Additional comments from crx...@openoffice.org Mon Jun 8 21:48:07 + 2009 --- @pl: great! Hey- N-up sounds like another really neat option! (If it is what I think it is- printing multiple pages on a single page side/face). But beware- I suspect that is another option that should probably always default to 1. At least there is far less damage (print resources) if that is accidentally left on, if you know what I mean. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 --- Additional comments from crx...@openoffice.org Sun Jun 7 16:26:18 + 2009 --- @christophnoack: No, it breaks nothing by having the print dialog remember the last collate setting used. The collate setting is not saved with documents (neither is the number of copies, for example). As long as it is not saved with the document, then remembering the last setting used will not break (interfere) with anything else. As far as using tools-options: I first proposed that we use tools-options-print by adding a selection for collate. But that was shot down by pl (read the 5th message from the top). I see the advantage and disadvantage of both approaches. It seems the most logical place to address it would be in tools-options. But the *easiest* (and fastest) way to address the problem is by just having the print dialog remember the last used setting; storing that state in some config file. The latter approach requires zero UI changes/testing. More importantly, pl has supposedly already added code for it to remember the state in the print dialog, so it is probably moot now to worry about it. I will just be happy if this is fixed in the next release- whatever form the fix takes. ANYTHING is better than the current behavior in 3.0.0 - 3.1.0 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 --- Additional comments from crx...@openoffice.org Wed Jun 3 11:42:56 + 2009 --- @mba: Oh, I understand WHY OO emulates collation- non-page-printers (cheap inkjet, for example) can't collate on their own. And before OO started really using CUPS, there probably weren't a whole lot of options to interact with printers correctly. And OO is not the only application under Linux that does this (it just affects us the most). It would be best left up to CUPS to handle the whole collate process. I don't know enough about CUPS to know if it has a readable property to determine if the printer can collate on its own. I also don't know if you can tell CUPS to do the collation, and CUPS will decide if the printer is smart or stupid and handle it properly, itself. This is, of course, the root cause of our issues. Perhaps this CUPS interaction concept should be yet another issue number, assigned to PRINT? @pl/mba: Our (my) problem would be 75% solved with just adding persistence. However, if there is no way for me to get the starting default to be OFF, some of my problem remains, since I am forced to rely on education to let every user know they need to change it manually, at least once. And, then, every time there is an upgrade. I would still hope for a sysadmin setting/config file, or environment variable or something. But I will take whatever I can get as a major improvement over what we have right now. :) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 --- Additional comments from crx...@openoffice.org Wed Jun 3 14:50:55 + 2009 --- @pl: yes (assuming persistence will last across dialog pop-ups AND across sessions) Thanks so much... sounds like at least that part could be pushed out quickly. @EVERYONE: I need to correct something I said in my very first posting... I implied the issue is only a problem when printing more than one copy of multi-page documents with collate ON. This is not correct, it is worse... The problem occurs even when printing more than one copy of *single-page* documents with collate ON! So 100 copies of a single 50MB page also sends 5000MB to the printer. I do wish I could find some type of hack to immediately change the default so I can roll out 3.1.0 here (our compiling OO is not an option). The problem is severe enough for us that I had to halt our rollout upgrade from 2.3 to 3.1 that we spent several weeks configuring, testing, and documenting :( Isn't there some secret file I can hack? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 User crxssi changed the following: What|Old value |New value CC|''|'jolatt,mba,regina' --- Additional comments from crx...@openoffice.org Tue Jun 2 21:07:09 + 2009 --- I agree that my UI suggestion be overdoing it a tad...as an administrator, I tend to like lots of options :) As an alternative, I suggest that the print dialog should be changed to remember the previously selected state for collate, for all users, and start off with collate unchecked (OFF) for new installs, since that it is the safest setting for all situations. Everyone will get what they want and need. Those irritated with the old behavior of it always reverting to uncollated will only have to check it once. Those who don't know the difference, don't care, or won't mess with it, will have a default that does not cause problems for page printers. Then for further refinement or lockdown, give options in the configuration file entry for the site administrator that could turn it off and/or hide it. I don't think having only a config file without changing the print dialog default behavior is good enough, since that presupposes that sites (and even end users) know there is the problem to begin with. For example, I didn't discover the problem until after implementation was already completed and OO 3.0/1 rolled out to users because I never thought to test multiple copies of large documents. It never occurred to me that OO would send hundreds of identical 50MB print jobs when collation used to work fine with collate off. After the network became saturated and server and end-user performance suffered, only then did I discover it... (and had absolutely no way to fix it). Whatcha think? A reasonable compromise? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 User crxssi changed the following: What|Old value |New value CC|'jolatt,mba,regina' |'hi,jolatt,mba,regina' Keywords| |regression Target milestone|--- |OOo 3.1.1 --- Additional comments from crx...@openoffice.org Tue Jun 2 21:24:18 + 2009 --- It would be useful to know if this issue only affects Linux or also other platforms as well. For example, if you set collate ON in MacOS version and send 2 copies of a 10MB multipage document to an intelligent page printer, does it send 20MB (2 x 10) to the printer or just 10MB? (It is easiest to determine this by including large bitmap graphics in the test document, then check the CUPS logs to see the size for a 1 qty print job, vs a 2 qty print job) Do note, however, that the proposed solution would not adversely affect other OS versions. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 --- Additional comments from crx...@openoffice.org Wed Jun 3 02:28:36 + 2009 --- Sorry, didn't know I wasn't supposed to set targets... perhaps wishful thinking? :) You imply it might not be a real problemtrust me, it is for sites like mine. We can't afford the network and CPU load that sending zillions of unnecessary copies of print job data places on us, especially when it is completely avoidable (since *all* our printers will always automatically collate). Anyway, I do agree with your reasoning about the issue type. It isn't necessarily an error (defect)... the inherent behavior of sending multiple redundant copies in the print job has always been there when collate was on, even before the defaults were changed. It is just that many of us wouldn't know about the problems (or have issues with it) until the option was forced as default on every time the print dialog appears. However, it is somewhat more that just an enhancement, because it is attempting to fix latent problems/issues that arose from the previous enhancement. Since there aren't all that many issue types in the QA system, I suppose enhancement would best fit... but with more of an urgency than a typical enhancement would justify. Fortunately, I believe the minimal fix (start OFF, then remember previous state across dialogs and sessions) is probably easy to define, understand, test, and implement, and with no negative consequences; all while retaining the original intent of the first enhancement: making it so nobody will have to constantly change the collate option flag. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 59506] Defaulting to collate pag es
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=59506 --- Additional comments from crx...@openoffice.org Sat May 30 13:03:36 + 2009 --- You took the words right out of my mouth! I *did* create a new issue, ( issue 101973 ), and it was quickly marked as a duplicate and closed! :) THIS issue (59506) was probably re-opened when it was realized that just changing the default created more problems than it supposedly fixed. Should I create yet another? Should Issue 101973 be re-opened? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 User crxssi changed the following: What|Old value |New value Status|CLOSED|UNCONFIRMED Resolution|DUPLICATE | --- Additional comments from crx...@openoffice.org Sun May 31 01:22:06 + 2009 --- Adding updated info from followup on issue 59506 here... Some people will want collate on as the default... just for convenience. Many people have asked for it, and unfortunately it was given to them in OO 3.0 without any real regard to the consequences. Many people will have severe problems with the default being on, and our business is one of them (as I explained in a previous comment, above). There might be some type of different options under other OS's (MSWin/MacOS), but under Linux it is very problematic using the collate function on. The suggestion about storing the collate setting per printer is probably not practical, since there is no user interface in OO that addresses saved options on a per-printer basis (unless they want to resurrect the spadmin tool, which is now pretty much dead). Storing such a setting in a document doesn't really make any sense. So the only best remaining way to handle the problem is to make an option in tools-printing that can hold a user's preference for collation: 1) Remember previously used state (begin with setting off) 2) Always default to off 3) Always default to on 4) Always remain off (and don't show option in print dialog) With the default setting for new installations set to #1 (since that is most logical). The above change would solve the problem for most people once and for all. Although there should also be a way that a system administrator can set the default for new users, to make the problem absolutely solvable on systems where printers do their own collation all the time (which is most modern laser printers and copiers). - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 59506] Defaulting to collate pag es
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=59506 --- Additional comments from crx...@openoffice.org Sun May 31 01:25:48 + 2009 --- I re-opened issue 101973 and added refined info from my other long posting here. Perhaps it will be left open and people monitoring THIS issue should go over there. At this point, I just don't care where it is, as long as people know there is a problem that needs to be solved. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 59506] Defaulting to collate pag es
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=59506 --- Additional comments from crx...@openoffice.org Fri May 29 21:54:21 + 2009 --- mba said: It seems that this was already implemented some time ago. Implemented where? When?. I am using 3.1.0 in Linux and I don't see any way to control the default behavior of collate user-wide, printer-wide, or system-wide. It is currently hard-coded to be ON and the user can only temporarily turn it off. Now, you might have some type of different option under some other OS (MSWin/MacOS) but not under the latest OO running under Linux. As I said before, it is currently a major mess for people running Linux using intelligent page printers (like mid-range/high-rage laser printers and copiers). - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 59506] Defaulting to collate pag es
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=59506 --- Additional comments from crx...@openoffice.org Wed May 20 22:27:31 + 2009 --- Some people will want collate on as the default... just for convenience. Many people have asked for it, and unfortunately it was given to them in OO 3.0. But many other people will have severe problems with the default being on, and our business is one of them (as I explained in a previous comment, above). The suggestion about storing the setting per printer is probably not practical, since there is no user interface in OO that addresses saved options on a per-printer basis (unless they want to resurrect the spadmin tool, which is now pretty much dead). Storing such a setting in a document doesn't really make any sense. So the only best remaining way to handle the problem is to make an option in tools-printing that can hold a user's preference for collation: 1) Remember previously used state 2) Always default to off 3) Always default to on 4) Always remain off (and don't show option in print dialog) With the default setting for new installations set to #1 (since that is most logical). That would solve the problem for most people once and for all. Although there should also be a way that a system administrator can set the default for new users, to make the problem absolutely solvable on systems where printers do their own collation all the time (which is most modern laser printers and copiers). - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 102071] Particular MS-Word doc r unaway when printing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102071 Issue #|102071 Summary|Particular MS-Word doc runaway when printing Component|Word processor Version|OOo 3.1 Platform|PC URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|printing Assigned to|writerneedsconfirm Reported by|crxssi --- Additional comments from crx...@openoffice.org Tue May 19 18:47:43 + 2009 --- We were sent a single-page MS-Word .doc file. Opened it in OO 3.1 and also OO 2.3 (and also on a different machine). It looks fine on the screen, but if we try to print it, it becomes a runaway process, consuming 100% CPU forever (we killed it after 10 min). However, if we create a PDF of it from OO, that only takes a few seconds and then we can print it fine with Acrobat Reader. I have not seen this type of behavior before, and we deal with lots of .doc files. Tried both options to reduce and not reduce transparency, didn't make any difference. While it is stuck in runaway it slowly eats away more and more memory, too. I do not know who created the document and with what. But it was sent to many people, including our business. It is attached to this issue. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 102071] Particular MS-Word doc r unaway when printing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102071 --- Additional comments from crx...@openoffice.org Tue May 19 18:49:00 + 2009 --- Created an attachment (id=62379) this MS-Word doc won't print in Linux OO, and causes a runaway - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 59506] Defaulting to collate pag es
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=59506 --- Additional comments from crx...@openoffice.org Fri May 15 20:45:07 + 2009 --- The behavior in OO 3.X was changed... Now the default in OO is to always have collate on in the print dialog, with no default choice allowed, without remembering the previous setting, and with no system-wide settings option. This is a now MAJOR problem for us. Under Linux/CUPS with network PS printers, the printer handles collation automatically. You just send a multipaged job to the printer, and the number of copies. The printer will repeat the job in it's memory quickly and efficiently. Now that the default in OO has changed, the users don't know that they are NOT supposed to check Collate. When you check that box, OpenOffice will generate the output N number of times. When a user requests 100 copies of a 50MB document, OO now sends 5,000MB of data to the printer. It causes tremendous waste of CPU (we are centralized with thin clients) and tremendous waste of network bandwidth. It also slows down the printing process. All because that default was changed. I can't find a way to change the default to OFF like it used to be before OO 3.X. We need an environment variable or a way to hack the config files in the installation directory. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[framework-issues] [Issue 95686] Collated printing setting not being remembered
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=95686 --- Additional comments from crx...@openoffice.org Fri May 15 20:53:45 + 2009 --- For us, the remembering of the state of collate was not a problem when the default was NO (OFF). However, the behavior in OO 3.X was changed... Now the default in OO is to always have collate on in the print dialog, with no default choice allowed, without remembering the previous setting, and with no system-wide settings option. This is a now MAJOR problem for us. Under Linux/CUPS with network PS printers, the printer handles collation automatically. You just send a multipaged job to the printer, and the number of copies. The printer will repeat the job in it's memory quickly and efficiently. Now that the default in OO has changed, the users don't know that they are NOT supposed to check Collate. When you check that box, OpenOffice will generate the output N number of times. When a user requests 100 copies of a 50MB document, OO now sends 5,000MB of data to the printer. It causes tremendous waste of CPU (we are centralized with thin clients) and tremendous waste of network bandwidth. It also slows down the printing process. All because that default was changed. I can't find a way to change the default to OFF like it used to be before OO 3.X. We need an environment variable or a way to hack the config files in the installation directory. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@framework.openoffice.org For additional commands, e-mail: issues-h...@framework.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[ui-issues] [Issue 101973] Collate print option defa ulting to on causes problems
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101973 Issue #|101973 Summary|Collate print option defaulting to on causes problem |s Component|ui Version|OOo 3.0 Platform|All URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|ui Assigned to|uineedsconfirm Reported by|crxssi --- Additional comments from crx...@openoffice.org Fri May 15 21:08:14 + 2009 --- The behavior in OO 3.0 3.1 was changed... Now the default in OO is to always have collate on in the print dialog, with no default choice allowed, without remembering the previous setting, and with no system-wide settings option. This is a now MAJOR problem for us. Under Linux/CUPS with network PS printers, the printer handles collation automatically. You just send a multipaged job to the printer, and the number of copies (with collate in the application OFF). The printer will repeat the job in it's memory quickly and efficiently producing a collated output. (It is extremely rare anyone would want uncollated, anyway). Now that the default in OO has changed, the users don't know that they are NOT supposed to check Collate. When one checks that box, OpenOffice will generate the output N number of times. When a user requests 100 copies of a 50MB document, and collation is ON in OO, it sends 5,000MB of data to the printer. It causes a tremendous waste of CPU (we are centralized with thin clients) and tremendous waste of network bandwidth. It also slows down the printing process. All because that default was changed. I can't find a way to change the default to OFF like it used to be before OO 3.0. We need an environment variable or a way to hack the config files in the installation directory. A better long-term fix would be to at least have a default setting for collate in tools-options. Have a three-way setting: always on, always off, and remember last setting. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@ui.openoffice.org For additional commands, e-mail: issues-h...@ui.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sc-issues] [Issue 101614] Format Cells, Numbers tab : display is very slow, delayed
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101614 User crxssi changed the following: What|Old value |New value Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Additional comments from crx...@openoffice.org Thu May 7 22:01:22 + 2009 --- I doubt you would be able to duplicate it in XP. But I did duplicate it, yet again, on another machine: my really fast Linux machine at home. On a fast machine, you almost can't see the delay, although it is there. In any case, 3.1.0 JUST came out, so I downloaded that and tested it at work with the thin client and the problem is SOLVED. So someone must have already noticed and fixed it 3.1 also loads much faster, and speeds up the mouse region selecting in Calc a LOT. Unfortunately, now I am having some performance problems in Draw... but that is a different subject :) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org For additional commands, e-mail: issues-h...@sc.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sc-issues] [Issue 101614] Format Cells, Numbers tab : display is very slow, delayed
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101614 Issue #|101614 Summary|Format Cells, Numbers tab: display is very slow, delay |ed Component|Spreadsheet Version|OOo 3.0.1 Platform|PC URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|formatting Assigned to|spreadsheet Reported by|crxssi --- Additional comments from crx...@openoffice.org Wed May 6 19:00:50 + 2009 --- In OO 3.0.1 Calc, when you call up format cells and it tries to display the Numbers tab, there is a very noticeable delay before anything appears. On this system, it is about two seconds before the Format Cells pop-up window appears on the screen. But it is related to the Numbers tab. If you select any other tab (like Font), then close/cancel the Format Cells window, then pull up the Format Cells window again, it is instant because it doesn't have to draw the Numbers tab. Now click on the Numbers tab with the Format Cells window already open, and there is the two second delay again. But once the Numbers tab is drawn, you can click on any other tab and return to the Numbers tab instantly. I have never seen this behavior before in OpenOffice (it didn't do this in 2.3 or 2.4). I am using the plain vanilla OpenOffice on Mandriva 2006.0 on a thin client. So I also tried it on a stand-alone machine with Mandriva 2009.1, with the Mandriva-compiled OO 3.01 RPM, and it acts exactly the same way! Something is very wrong with the Numbers tab. On this machine, if you call up the Format Cells window by right clicking in a call, it doesn't even get rid of the right-click dialog for those two seconds. I don't know what is wrong, but during that delay, there is 100% CPU usage. I am sure on faster machines, the delay is smaller, but on slower machines, it is quite noticeable and frustrating. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@sc.openoffice.org For additional commands, e-mail: issues-h...@sc.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[graphics-issues] [Issue 47689] rectangles toolbar doesn't work
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=47689 --- Additional comments from crx...@openoffice.org Tue Apr 28 21:33:20 + 2009 --- I am very glad this is being fixed! It has annoyed me for many years now. But will it be possible to change the default menus for OpenOffice so that instead of the simple elipse and rectangle tools that are on the toolbar the elipse MENU and rectangle MENU replace them, like it was in OpenOffice 1.X? It makes a lot more sense to have the fly-out menus available by default so users don't have to go digging through several layers of menu customization just to create a square or rounded corner rectangle. Any serious Draw user will greatly appreciate it, and it won't offend new users, since it isn't complicated nor does it eat up toolbar space. Maybe I don't understand why the default choices were changed in OOo 2.X. There might be some good reason, but I can't think of one! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[sw-issues] [Issue 58919] Blank Pages in Mail Merge
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=58919 --- Additional comments from [EMAIL PROTECTED] Thu Aug 14 12:17:49 + 2008 --- I really don't mean to beat a dead horse, but... The reason there are so many duplicates for this issue is because it is NOT RESOLVED. WONTFIX is not suitable. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gsl-issues] [Issue 83388] Parent frame with no borde r causes child frame transparency to go to 100 %
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83388 --- Additional comments from [EMAIL PROTECTED] Mon Jun 23 13:48:28 + 2008 --- I have not tested this thoroughly, but it appears that SAL_DISABLE_NATIVE_ALPHA=TRUE does, indeed fix the problem on my system (Linux 00 2.3.0). This is the first time I have been able to properly print pages with transparent frames since 2.1.0. This makes me very happy, even though it really isn't fixed. So, the questions is, what are the side effects, negatives, or consequences of setting SAL_DISABLE_NATIVE_ALPHA=TRUE ? Is it going to create other issues that I am not aware of yet? What exactly is the purpose of Native Alpha? http://wiki.services.openoffice.org/wiki/Environment_Variables doesn't say anything useful. Thanks! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[gsl-issues] [Issue 83388] Parent frame with no borde r causes child frame transparency to go to 100 %
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83388 --- Additional comments from [EMAIL PROTECTED] Mon Jun 23 17:49:39 + 2008 --- thb: Thanks for the info. I have been using writer with SAL_DISABLE_NATIVE_ALPHA=TRUE much of the day now. I can't say I notice any difference in rendering speed yet... which is a good thing. (We use Linux based thin clients displaying OO 2.3.0 from a central Linux server at 100Mb/s). I wish there were a way I could help more on a real fix, but I am not a programmer. However, if you need any additional testing or sample files, etc, let me know. I still think there is a design flaw in OO if it is using the Xserver to render (in any way) for PRINTING purposes (I know it is, because when I print a huge newsletter, it creates insane network activity to the local thin desktop and almost freezes everything- sometimes for minutes). - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 59483] Tile printing gives unexpe cted result
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=59483 --- Additional comments from [EMAIL PROTECTED] Sun Apr 20 12:55:40 + 2008 --- I believe this was finally fixed in OO 2.3.0, that is why you haven't heard much about it. I would want someone else to verify, though. Anyone responding, please use issue 35616, not this closed one. I only posted here so people monioring this closed (duplicate) issue will see. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 35616] Posterized printing skips pages
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=35616 --- Additional comments from [EMAIL PROTECTED] Sun Apr 20 13:00:22 + 2008 --- I believe this was finally fixed in OO 2.2.0 or 2.3.0 (I skipped over some versions), that is why you haven't heard much about it. I would want someone else to verify, though. While waiting for this issue to be fixed, in 2.2.0 a *much* more serious printing issue appeared that hurts us even more :( (issue 83388) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 35616] Posterized printing skips pages
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=35616 --- Additional comments from [EMAIL PROTECTED] Mon Apr 21 01:49:44 + 2008 --- Let me clarify. I did not try his test document (because there was no need). However, tiled printing *was* very much broken, and in the manner described (two or top pages print something, lots of blank other pages or pages with gibberish, no matter what type of tiling I used and no matter which printer). At some point between 2.2 and 2.3 it was fixed for me. I print large diagrams and had to transfer them over to ancient OO install to print them. I can now print them fine, I just don't know exactly when it was fixed. We do not, however, use an A4 printer. Everything is either US letter or US tabloid sized, usually printed tiled across 4 such pages (2x2). - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 4499] Export to bitmap file has f ixed DPI (resolution)
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=4499 --- Additional comments from [EMAIL PROTECTED] Sat Mar 15 23:30:24 + 2008 --- We just need to have variable raster export resolution control and have something higher than OO's fixed max, which is currently about 2048x2048. Personally, I don't care what it is called (res, dpi, lpi, ppi), as long as it rasterizes at something the user specifies. It does seem that ppi is the most logical name, however. To me, an export is printer-irrelevent. If I wanted to print it from OpenOffice, I would use the print function. Shouldn't matter which printers I have defined or available in OO for the export function. I think in total resolution of my output, so for me, I want to know I am getting 1600x1200 or 3200x2400 or whatever. When exporting, DPI/PPI/LPI really means that if I am exporting at 600DPI, for example, then my 8x10 page (from page format in OO Draw) will result in a 4800x6000 jpg or png (or whatever), which is not currently possible. The mockup is OK, and placing it in page format kinda makes sense (as long as the export filters honor it). Only thing I would change is to rename it from resolution to export resolution, because it might otherwise confuse people. It doesn't change anything when printing or viewing or saving or anything else except for rasterized export. I don't know where the rasterization occurs. Does the export filter do it? Or is it done by OO internally and the result is passed to the filter for post-processing? I suspect it is internal to OO, because that is why we are hitting a consistent upper size limit. If this is the case, then there is a single, internal rasterization routine that will need to be modified to allow it to become much bigger when necessary (warning: this could eat up a LOT of RAM... might be a good idea to have it also honor some max RAM setting in Tools-Options). If one challenge is the necessity to modify all the filters- I would suggest concentrating first (or even only) on the only two that will matter the most to most people- jpg and png, and worry about the others later. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 58919] Blank Pages in Mail Merge
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=58919 --- Additional comments from [EMAIL PROTECTED] Sat Mar 15 23:45:45 + 2008 --- That was suggested in this thread two years ago by intersol. But I still wouldn't consider it fixed, I would consider that to be a workaround 1) The merge shouldn't put extra pages in, unless the user chooses to do so. Most users will have no idea why extra pages would be a hard-coded default (me niether) 2) Most users wouldn't know where to go to try and change the supress setting. 3) What is on the screen is confusing, regardless, with the strange left/right page numbering. 4) I think supressing the extra pages in the print dialog will not help with save as, when you create a report or something and want to export it as an ASCII text file for futher editing. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 4499] Export to bitmap file has f ixed DPI (resolution)
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=4499 --- Additional comments from [EMAIL PROTECTED] Sun Mar 9 15:27:19 + 2008 --- Vtdiy, I would not recommend putting such a setting in Format. To me, the most logical place to ask about export resolution is when you export, which would be in the export dialog. If you do write up something, see my previous posting- there are at least four things that need to be addressed: 1) The DPI setting has no effect when exporting 2) The maximum resolution for raster exporting is too low 3) There is no user choice in export resolution 4) There is no user feedback for actual resolution during an export Just asking the user for (an honoring) a resolution is only 2 of the 4 issues. I would also caution against only using the term DPI, since exporting really has nothing to do with Dots Per Inch... that is only meaningful when printing. It is better to relay resolution in total pixels (like 1650x1275) or show both (like 150DPI 1650x1275). For the ultimate in convenience, show and let the user set any of DPI, resolution, and Megapixels (150 DPI 1650x1275 2.1 MP), then the user wouldn't have to do any math :) I could see adding a 5, to the above, also: 5) There is no place to set the default export resolution Which would probably be in Tools-Options - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 4499] Export to bitmap file has f ixed DPI (resolution)
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=4499 --- Additional comments from [EMAIL PROTECTED] Sat Mar 8 19:50:29 + 2008 --- It means they don't expect it to be fixed for the next release. It is much better than marking it WON'T FIX or INVALID like what happens with some problems. Having an actual target listed, rather than just a generic OOLATER is also a good sign. Targets are just guesses as to which release a fix might be made, not promises. Bug fixes, where something is actually broken, take priority over enhancements, like this one. At some point they have to stop making changes in order to push out a new release. Then the cycle begins again. I don't know exactly how enhancements are prioritized, but those with more votes are likely to end up nearer the top of the list. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 47689] rectangles toolbar doesn't work
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=47689 --- Additional comments from [EMAIL PROTECTED] Tue Feb 5 12:42:47 + 2008 --- Three year old bug. Clearly described. Reproduced by many. Still broken. Still marked as NEW! Ug!! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 83388] Parent frame with no borde r causes child frame transparency to go to 100 %
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83388 --- Additional comments from [EMAIL PROTECTED] Thu Jan 24 15:00:15 + 2008 --- I have new information. The problem also occurs under OpenOffice 2.2.0 under Linux. I will attached three postscript outputs for the sample test document that I first attached. It is the output of each for 2.1.0, 2.2.0, and 2.3.0. I would be happy to install additional older OpenOffices if we need to narrow down exactly when it started between 2.1.0 and 2.2.0. I would also welcome someone to send me their generated postscript of the test document from 2.3.0 and I will print it here and see if it comes out correctly or not. od: I am not sure how the Linux printing system could be the cause of the issue, unless there is something inherently different between the postscript that 2.1.0 generates and that of 2.2.0. Hopefully the new attachments would assist someone that is fluent in postscript to notice the difference. Also of importance is to note that this is not the only problem we are having with printing documents with transparencies in newer OpenOffices... I have some other examples, too. But I don't want to complicate the bug reporting yet, unless there is a need for more information. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 83388] Parent frame with no borde r causes child frame transparency to go to 100 %
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83388 --- Additional comments from [EMAIL PROTECTED] Thu Jan 24 15:02:17 + 2008 --- Created an attachment (id=51138) test document, printed from 2.1.0, correct output - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 83388] Parent frame with no borde r causes child frame transparency to go to 100 %
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83388 --- Additional comments from [EMAIL PROTECTED] Thu Jan 24 15:03:45 + 2008 --- Created an attachment (id=51139) test document, printed from 2.2.0, incorrect output - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 83388] Parent frame with no borde r causes child frame transparency to go to 100 %
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83388 --- Additional comments from [EMAIL PROTECTED] Thu Jan 24 15:04:52 + 2008 --- Created an attachment (id=51140) test document, printed from 2.3.0, incorrect output - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 81713] PDF Export option to creat e pdf layers from Draw layers
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81713 --- Additional comments from [EMAIL PROTECTED] Thu Jan 24 21:00:45 + 2008 --- I agree that this could be a useful enhancement for all platforms. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 61274] PDF export shows layers th at are marked for not printing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=61274 --- Additional comments from [EMAIL PROTECTED] Thu Jan 24 21:06:26 + 2008 --- Add me as a me too. I believe that the PDF export in Draw should only export the layers marked for printing. Right now, I have to go through a dozen layers and actually delete them before making a PDF! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[framework-issues] [Issue 20065] Q-PCD Easier way to manage layers
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=20065 --- Additional comments from [EMAIL PROTECTED] Thu Jan 24 21:32:12 + 2008 --- OK, it is wy later now (Target milestone = OOo Later)... might be time to reconsider the layers management in OO Draw. Has been 4 years since first posted about version 1.0.0. Not much has improved on the layers tabs in 2.3. It really can be a pain working with lots of layers: 1) The user cannot just grab a layer tab and move it to reorder layers 2) In fact, the user cannot re-order the layers at all! There is no method. 3) The names of the layers are supposed to appear blue when the layer is not visible. Most of the time it just doesn't work- they are not blue. I open documents with non-visible layers all the time and the tabs are not blue- but if I modify them and change nothing and click on OK, that ONE layer tab will temporarily have blue text. 4) Having to turn on/off visibility of several layers is very time consuming, you have to double click on the tab, wait for it to appear, change the visibility, then OK, then do it all again. Why not have a right-click on the tab with a checkmark for visibility and printability? 5) Tabs should be color coded for visibility/print/lock. For example, blue text if not visible. Red background if locked. Yellow outline if not printable. It might also be nice to have a separate, multi row/column dialog for controlling all layers at once, as CJ suggested (under view-layers). (Compare to the way the GIMP layer dialog works.) Just some ideas! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[framework-issues] [Issue 85442] Printing transparencies re nders on Xserver
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=85442 --- Additional comments from [EMAIL PROTECTED] Wed Jan 23 02:27:17 + 2008 --- Actually, that is what I figured. It was probably far easier (and faster) at the time to just render on the Xserver, since that was available and working. Thin clients are nothing new, yet certainly not going away. Hopefully, one day it can be fixed. There might already be methods for doing this in other *ix applications... but I am not well versed in that area, so I can't know, either way. Thanks for listening :) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 83388] Parent frame with no borde r causes child frame transparency to go to 100 %
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83388 --- Additional comments from [EMAIL PROTECTED] Mon Jan 21 14:43:13 + 2008 --- It is not the same issue at all. And, I don't even think issue 80316 is valid- his child frame is clearly marked to wrap in background, and that is exactly what OO does. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 80316] Nested frames: inner one s hows bodytext though non-tranparent
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=80316 --- Additional comments from [EMAIL PROTECTED] Mon Jan 21 14:43:18 + 2008 --- I don't think this is a valid issue. Look at his child frame in the sample document. It is marked to wrap in background, and that is exactly what OpenOffice writer does- it puts the child frame in the background. So, of course the parent frame is going to show through! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 80316] Nested frames: inner one s hows bodytext though non-tranparent
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=80316 --- Additional comments from [EMAIL PROTECTED] Mon Jan 21 14:49:16 + 2008 --- I should clarify: It isn't exactly clear what OpenOffice means by in background, for frame wrapping, but: 1) The described behavior is exactly what OO has always done. 2) I can't think of any other meaning for in background if OO writer doesn't behave this way. 3) I like to think of in background as meaning make this frame not wrap and go behind other frames as if the other frames were transparent, except for the background. 4) You can see that it really is not transparency because if you set different colors on the backgrounds of the parent and child frames, they don't combine. The child background takes precedence. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[framework-issues] [Issue 85442] Printing transparencies re nders on Xserver
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=85442 Issue #|85442 Summary|Printing transparencies renders on Xserver Component|framework Version|OOo 2.3.1 Platform|All URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|ui Assigned to|tm Reported by|crxssi --- Additional comments from [EMAIL PROTECTED] Mon Jan 21 15:11:51 + 2008 --- This is something that causes a problem in our environment. We use thin-client Xterminals. A Xterminal runs only the Xserver- the applications reside on a different Linux/Unix central host. Only the graphics output are sent to the Xserver, and the Xserver sends back mouse and keyboard events to the Xhost. Start with a Writer or Draw document that contains partially transparent objects. They can be simple transparent objects or transparency in frames. I suspect it will also do this in Impress. Next, try to print the document. You will be warned if you want to reduce transparency. Answer no, because you really want it. Now watch the network. During a long wait, OpenOffice is apparently uses the Xserver to compute the transparency rendering! It has to pass huge blocks of data from the application to the Xserver. If you have a large or complex document, and a slower network, the user can be stuck waiting for 5, 10, even 20 minutes! And during that time, the network is saturated (possibly in both directions), preventing the user from using other applications. There seems to be a flaw in the design of OpenOffice that assumes the Xserver will ALWAYS be local- running on the same machine as OpenOffice, itself. That assumption is a violation of the [client/server] design model for the X Windows System. Granted, most modern OpenOffice users will have machines that run both the Xserver and OpenOffice on the same machine, but it *can* cause problems for people who use a thin model. With the current design, the speed of rendering is tied directly to the speed of the network. I have a feeling it was just easier to use some routines in the Xserver to do the transparency, instead of writing new ones, and that most Unix/Linux users would never know. Is there a way to stop using the Xserver to perform rendering for printing? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 4499] Export to bitmap file has f ixed DPI (resolution)
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=4499 --- Additional comments from [EMAIL PROTECTED] Sat Jan 19 15:23:08 + 2008 --- Markellse, why do you think this issue has been fixed? I have seen no indication that there has been any fix on this six-year-old issue. You are right that sometimes things are fixed and we don't know about it, because the issues aren't marked that way until much later. And often things are fixed or enhanced and not even mentioned in the release notes. For example, when 2.3.0 came out, OO *finally* had the ability to use a page size greater than 48 or whatever the max used to be. But I ran across it completely by accident- this major new ability was not mentioned anywhere. In any case, I have 2.3.1 installed and no, it is not fixed. When I export to a jpeg (or other raster format), I am not asked what resolution I want, it doesn't tell me how big the raster file will be (in pixels), the export resolution is mysteriously based on page size, and the maximum rasterized output resolution was 2250x2048. Nothing has changed. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 83620] Typo in Mail Merge dialog
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83620 User crxssi changed the following: What|Old value |New value Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Additional comments from [EMAIL PROTECTED] Thu Jan 17 17:24:01 + 2008 --- OK, well, I tried to reproduce it in 2.3.0 and now it says Save as single document and Save as individual documents. So apparently I was somehow mistaken on my bug report. I have closed this issue as invalid. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 58919] Blank Pages in Mail Merge
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=58919 --- Additional comments from [EMAIL PROTECTED] Mon Jan 14 21:54:43 + 2008 --- Well, I would love to know how to make the developers take notice that it is a pretty serious problem that should be fixed and the current behavior really is broken. There have been half a dozen duplicate bug reports, and many people who are not satisfied. I fear once it is resolved as wontfix, that is the end. Any new postings of a similar nature will just point back to this one. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 4499] Export to bitmap file has f ixed DPI (resolution)
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=4499 --- Additional comments from [EMAIL PROTECTED] Mon Nov 26 23:27:11 + 2007 --- This is not new information, but I haven't seen it posted anywhere on this issue. It might actually constitute sever issues. The maximum resolution you can export in Draw is 2048x2048. It is impossible to export a PNG or JPEG of any greater resolution. If you are looking for a high-quality rasterized output for printing, the printed result is only 3.4 wide at 600dpi or 1.7 wide at 1200dpi. Even at a very low 300dpi, it is only 7 wide, not enough to fill a typical letter sized paper. And to get the maximum 2048 wide export, you have to lie about the paper size, choosing a huge 30+ paper size and resizing your graphics to fit the page, prior to exporting. This [artifically low] resolution limit severely cripples Draw for any serious graphics work. For example, I might want to make a collage of a few dozen photographs and then save it as a JPEG to be sent to a photo developer for a large print. Right now, we can only export a 3 megapixel output! Another example- I have a complex network diagram, I want to export it so I can send it to a printing business to blow up onto a 4 foot wide poster. They don't accept ODF or any of the few vector formats supported in OO. I have to use JPEG. The result- a printed diagram that can't be read due to low resolution. Note that DPI really is just a hint in a graphics file, it really doesn't mean anything until it is time to display or print it. It would exceptionally useful if the export dialog asked the user the desired resolution and told the user the actual number of pixels wide by pixels high. In summary: 1) The DPI setting has no effect when exporting 2) The maximum resolution for raster exporting is too low 3) There is no user choice in export resolution 4) There is no user feedback for actual resolution during an export (Please note that someone should change the platform setting on this issue, it is not MS-Windows XP specific, it affects all platforms.) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 58919] Blank Pages in Mail Merge
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=58919 --- Additional comments from [EMAIL PROTECTED] Wed Nov 14 12:28:47 + 2007 --- I am absolutely blown away that this is now marked as WONTFIX! It is most certainly a BROKEN behavior. Let's analyze: 1) 90%+ of printers in use today are simplex, not duplex. So it breaks the behavior on 90% of the printers. This is an exaggeration. I would be glad to provide a poll of my 100+ user Linux user's group, if you like. If you really felt it was necessary to insert blank pages for duplex printers, then check the current printer properties to see if duplex is on by default before ruining the document. 2) Even on duplex printers, it is not necessary to send blank pages, unless you are actually using it in duplex mode at the time. All duplex printers I have ever used (and I have used many) do not enter duplex mode unless specifically requested by the application, or if left permanently on in the printing subsystem (which is also exceedingly rare). 3) People don't necessarily want to use the complicated wizzard for a merge. In many cases, wizards can be more complex than just doing what you want without going through lots of additional questions. 4) Saving a merged file is not the same function as printing directly. So even if most printers were duplex (which they most certainly are not), saving the file should NOT have the behavior. 5) I can almost guarantee that the vast majority of users are going to be confused and irritated by the current behavior of inserting unnecessary blank pages. 6) Yes the page number indicator is wrong, it should not always show you as being on page one. If I start a brand new document and insert several hard pages, it works correctly- it doesn't say I am on page 1 for every page I move to. Of course, this could be some other type of bug and unrelated to this issue. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 58919] Blank Pages in Mail Merge
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=58919 --- Additional comments from [EMAIL PROTECTED] Wed Nov 14 14:41:51 + 2007 --- Regarding PDF- you are confusing me with hvedk... I never used that example, although I agree with his logic. I consider the extra pages as a contamination of the resulting merged output. It makes it difficult to print, difficult to review, and difficult to convert to PDF. As for the wizard- I hate it. It is confusing, long, and doesn't do at all what I want to do, which is to simply grab a few fields from a spreadsheet and place them in a docuemnt I have already designed. I do understand your explanation, I just still don't agree with it. I think it is more broken in its current form, for more people, than it would be if the blank pages were not added. If the user WANTED to print it in duplex, then having the merge contain extra blank pages defeats that and makes them print simplex. If the merge had no blank pages, it will still not print in duplex unless the user had the printer locked down to ALWAYS print EVERYTHING in duplex. And I have *never* seen anyone do that (in 22 years as an IT professional). Typically, using merge, the user will want separate physical pages for each record. But that is not ALWAYS the case. In WordPerfect, for example, I use merging all the time to make fancy reports in which there are more than one record on a printed page. I also use merging to create multipart pages, in which one page will be cut into separate physical parts later. Inserting blank pages (or even new pages in these cases) tends to make that even more difficult. I belive I understand some of the constraints with duplex. But at a very minimum- there should be a choice in the merge dialog if the user wants to have artifically added blank pages or not, with the default being no. I would propose this: Page Control: [ ] Streaming- no pages breaks between records [*] Page breaks- each record on a separate page [ ] Page breaks plus an extra blank page - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 83620] Typo in Mail Merge dialog
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83620 Issue #|83620 Summary|Typo in Mail Merge dialog Component|Word processor Version|OOo 2.3 Platform|All URL| OS/Version|All Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P4 Subcomponent|ui Assigned to|mru Reported by|crxssi --- Additional comments from [EMAIL PROTECTED] Tue Nov 13 21:26:05 + 2007 --- There is a typo in the Mail Merge dialog. Under Save merged document there are two options. They are Save as single document and save as individual document. Linguistically, those two phrases are identical in English. I think they meant to say Save as individual documents with an s on the end. Otherwise it is quite confusing as to how the two options differ- that one will create a single file and the other will create multiple files. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 58919] Blank Pages in Mail Merge
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=58919 --- Additional comments from [EMAIL PROTECTED] Tue Nov 13 23:05:56 + 2007 --- This is a serious issue... and still confusing and irritating my users in version 2.3, almost two years after joesny first reported it. Under no case should blank pages be added to a merge document, unless the user has specifically requested it... and there are no such options in any merge dialog. Starting a new page with each record makes perfect sense, but not adding blank pages. If I open a saved, merged document that was a one page form merged with three records, I expect three pages. Instead, I get content, blank, content, blank, content. That is FIVE pages. When I click on the first page, the page indicator says Page 1/5 when I then click on the only other next page I can find, it says Page 1 3/5!! So something is also trying to hide the blank pages, making them extremely difficult to remove or even see, and messing up the page indicator too. They are visible, however, if you do a page preview of the document. I don't see how this really has anything to do with duplex as has been suggested in other comments. In our case, no printer or printer settings are ever set to duplex before or after merging a document. If this problem was created with duplex in mind, then the document should have been 6 pages in the above example, not 5. And, although this is probably not the appropriate location for the comment- there should be a THIRD option in the UI for the merge dialog, create and open new document. It should be unnecessary to print the document to a file, then turn around and manually open the document to look at it. Simply open up a new window with the new, merged document in it. And that should be set as the default option- not printing, not saving to a single file, not saving to multiple files. If you check user behavior- I bet 90%+ of people will want to look at what they merged to make sure it is correct, before printing it. Currently, this means always having to save it out, then having to open it back up again. And this blank page bug is validation as to why users want and need to look at the document before printing. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 83381] Parent frame with no borde r causes child frame transparency to go to 100 %
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83381 Issue #|83381 Summary|Parent frame with no border causes child frame transpa |rency to go to 100% Component|Word processor Version|OOo 2.3 Platform|All URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|printing Assigned to|mru Reported by|crxssi --- Additional comments from [EMAIL PROTECTED] Tue Nov 6 18:15:41 + 2007 --- In OO 2.3 there is a new problem that did NOT occur in 2.1: How to reproduce: If you create an OO Writer document, insert a frame, set a background bitmap image to area, anchor to page. Make that frame rather large. Then go inside that frame and insert another frame, anchored to paragraph, set a white background, then set transparency to, perhaps 25%. Then type some text in the frame. Now print the document. In both 2.1 2.3 it will print properly- you will see about a 25% transparency in the top/white frame. Now turn off the border on the parent frame that has a background bitmap set and print the document. In 2.1 it will print properly. In 2.3 the top/white frame will suddenly change to 100% transparency. It will look OK on the screen or in a PDF you create from 2.3, but it will not print properly. I have repeated the test many times, to several printers, as several users. This is a fairly severe problem for us, because our company newsletter uses partial transparent frames like this. It took me MANY hours of troubleshooting the documents to finally narrow down this problem so I could find what causes it and so I could report it. Users not knowing this information might go crazy trying to figure out what is broken. Workaround: Our only work around has been to turn on a border on the lowest frame, making it the same color as the paper (white) and with no spacing. This workaround is successful on some documents, but not others. I will attach a sample document to this issue so it can be tried on other platforms and other OO versions by testers so the root cause can be corrected. I would be happy to attach additional documents as needed- more samples, scans of the prints, postscript of the prints, etc. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 83388] Parent frame with no borde r causes child frame transparency to go to 100 %
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83388 Issue #|83388 Summary|Parent frame with no border causes child frame transpa |rency to go to 100% Component|Word processor Version|OOo 2.3 Platform|All URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|printing Assigned to|mru Reported by|crxssi --- Additional comments from [EMAIL PROTECTED] Tue Nov 6 19:13:58 + 2007 --- In OO 2.3 there is a new problem that did NOT occur in 2.1: How to reproduce: If you create an OO Writer document, insert a frame, set a background bitmap image to area, anchor to page. Make that frame rather large. Then go inside that frame and insert another frame, anchored to paragraph, set a white background, then set transparency to, perhaps 25%. Then type some text in the frame. Now print the document. In both 2.1 2.3 it will print properly- you will see about a 25% transparency in the top/white frame. Now turn off the border on the parent frame that has a background bitmap set and print the document. In 2.1 it will print properly. In 2.3 the top/white frame will suddenly change to 100% transparency. It will look OK on the screen or in a PDF you create from 2.3, but it will not print properly. I have repeated the test many times, to several printers, as several users. This is a fairly severe problem for us, because our company newsletter uses partial transparent frames like this. It took me MANY hours of troubleshooting the documents to finally narrow down this problem so I could find what causes it and so I could report it. Users not knowing this information might go crazy trying to figure out what is broken. Workaround: Our only work around has been to turn on a border on the lowest frame, making it the same color as the paper (white) and with no spacing. This workaround is successful on some documents, but not others. I will attach a sample document to this issue so it can be tried on other platforms and other OO versions by testers so the root cause can be corrected. I would be happy to attach additional documents as needed- more samples, scans of the prints, postscript of the prints, etc. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 83388] Parent frame with no borde r causes child frame transparency to go to 100 %
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83388 --- Additional comments from [EMAIL PROTECTED] Tue Nov 6 19:16:08 + 2007 --- Created an attachment (id=49477) OO Writer document that will not print properly under OO 2.3 but does print properly under 2.1 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 83020] Intelligent connector rout ing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83020 --- Additional comments from [EMAIL PROTECTED] Mon Oct 29 20:51:50 + 2007 --- You are correct, it is an enhancement... that is why I set the Issue type to Enhancement :) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 83019] Add glue points to connect ors
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83019 --- Additional comments from [EMAIL PROTECTED] Mon Oct 29 20:54:08 + 2007 --- Wow- I searched and didn't find the duplicate before I created the new issue! Sorry about that. Yikes- the duplicate was from 4 years ago! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 47689] rectangles toolbar doesn't work
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=47689 --- Additional comments from [EMAIL PROTECTED] Fri Oct 26 16:18:00 + 2007 --- I have verified the rectangle menu item is also broken also under Linux OpenOffice 2.2 and Linux OpenOffice 2.3. The elipse menu item works fine, though. And, btw, instead of the simple elipse and rectangle tools that are on the toolbar (by default) it really should be put back to the elipse MENU and rectangle MENU, like it was in OpenOffice 1.X. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 58700] Page Page will not stay of f/away
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=58700 --- Additional comments from [EMAIL PROTECTED] Fri Oct 26 16:22:01 + 2007 --- I reported this issue almost two years ago. It is still not fixed in OpenOffice 2.1, 2.2, or 2.3. I verified it today. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 83019] Add glue points to connect ors
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83019 Issue #|83019 Summary|Add glue points to connectors Component|Drawing Version|OOo 2.3 Platform|All URL| OS/Version|All Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|ENHANCEMENT Priority|P5 Subcomponent|editing Assigned to|cgu Reported by|crxssi --- Additional comments from [EMAIL PROTECTED] Fri Oct 26 18:38:02 + 2007 --- It would be very useful to have the ability to add glue points to connector lines. This way the user could create connectors that connect to other connectors at places other than the two endpoints. For example- it would be possible to have what appears to be a single connector that connects to more than two objects. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 83020] Intelligent connector rout ing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83020 Issue #|83020 Summary|Intelligent connector routing Component|Drawing Version|OOo 2.3 Platform|All URL| OS/Version|All Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|ENHANCEMENT Priority|P5 Subcomponent|editing Assigned to|cgu Reported by|crxssi --- Additional comments from [EMAIL PROTECTED] Fri Oct 26 18:41:17 + 2007 --- It would be nice to have an attribute that could be placed on connector lines that allow them to intelligently route themselves. Using such a feature, when a connected object is moved, the connector line tries to avoid going through other objects and other connectors. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 83001] Open/Save Word 2007 Docx d ocuments
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=83001 --- Additional comments from [EMAIL PROTECTED] Fri Oct 26 19:09:24 + 2007 --- I also searched and could not find an issue about docx, other than yours. This surprises me, too. The docx file format is still rather new, but it has been out for several months and my users are already starting to get them every now and then. In the coming months/years, it will be critical to have the ability to not only open but also save OO files in .docx format (unfortunately). There is a method for converting them on the command line using a utility from Novel called OdfConverter- but it is released as a Linux binary-only. Some info here: http://geekhacks.blogspot.com/2007/05/working-with-word-2007-documentsdocx-in.html - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[framework-issues] [Issue 81407] Adding more than one color in one session, causes OOo to crash
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81407 --- Additional comments from [EMAIL PROTECTED] Fri Oct 19 14:20:24 + 2007 --- I know this is fixed for later releases, but I want to verify it also does this on Linux OO 2.3.0. I can add two colors; as soon as I add the third color, WHAM: /oa/openoffice.org2.3.0/program/soffice: line 251: 29215 Segmentation fault $sd_prog/$sd_binary $@ - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[framework-issues] [Issue 81407] Adding more than one color in one session, causes OOo to crash
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=81407 --- Additional comments from [EMAIL PROTECTED] Fri Oct 19 14:36:02 + 2007 --- I meant to also add that the problem is pretty severe and it isn't just that you can add one color at a time. It simply is not possible to add more than one new color, EVER. Even if I exit out of options and go back in, I still can't add another color. Even if I save and exit out of OpenOffice completely, go back in to options and try to add more more color, it crashes. It also crashes the same way when you try to add colors through Area, rather than through Tools-Options. The ONLY way I could get my 7 custom colors into OpenOffice was to replace (modify) existing Chart X colors. Hopefully this won't cause a problem with the new charting functions... This is a critical flaw. Since it was reported on RC1, it should NOT have made its way into the live/final/released 2.3.0 :( Without a workaround for the released version, many of us are stuck with a very bad problem. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 5088] Spell checker doesn't flag duplicate words
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=5088 --- Additional comments from [EMAIL PROTECTED] Thu Oct 18 11:54:57 + 2007 --- LanguageTool, (www.languagetool.org) is big and complex, and requires a specific (too new) version of Java that most users will not have installed. IMHO, way overkill to check for duplicate words. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 75219] Autocorrect: Duplicate Wor d Detection/Correction
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=75219 --- Additional comments from [EMAIL PROTECTED] Thu Oct 18 11:57:53 + 2007 --- I am glad that an API is being implemented (finally). Although a rule for duplicate words should apply to all languages, equally. LanguageTool, (www.languagetool.org) is big and complex, and requires a specific (too new) version of Java that most users will not have installed. Way overkill to check for duplicate words. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 72076] Dot (leader) tabs do not a lways print
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=72076 --- Additional comments from [EMAIL PROTECTED] Sun May 13 13:03:09 + 2007 --- You are correct. It seems to have been fixed in 2.1.0. I thought whomever fixed the problem would have closed the issue, or I would have come back and closed it myself. Thanks! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 76780] Clone objects that sync
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=76780 Issue #|76780 Summary|Clone objects that sync Component|Drawing Version|OOo 2.2 Platform|All URL| OS/Version|All Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|ENHANCEMENT Priority|P3 Subcomponent|code Assigned to|wg Reported by|crxssi --- Additional comments from [EMAIL PROTECTED] Sat Apr 28 13:45:39 + 2007 --- I just thought of a new feature that would save me (and presumably tons of other people) lots of time and frustration. Not sure what to call it, so I will call it cloning objects for now (although linking objects might also be appropriate). For all I know, this feature might exist in other drawing programs. Wouldn't it be wonderful if an object or group of objects could be cloned instead of copied (like a symbolic file link)? The cloned object or group would then appear on the screen and could be moved and possibly a few transforms (position, size, orientation). With the exception of the few transforms, if you try to edit the object or group, it would change all the clones in the document. It is almost a logical extension to the OpenOffice styles philosophy. Plus, these clones will take up very little space in the document file. They would allow the user a hugely productive tool. There are many times I find myself making n-up documents in Draw- where I want the same group of objects several places on the screen. But if I decide to make a change, I have to delete all the copies, make a change, then copy and resposition all the copies. Syncing clones would eliminate that problem completely. Another example- when I draw complex diagrams and use the same group of objects that form a symbol that are used all over the diagram. Many times I have wanted to just change one symbol and have them all change, but I don't see a way to do that in OpenOffice Draw. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 29150] Rotate text 180 degrees
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=29150 --- Additional comments from [EMAIL PROTECTED] Tue Apr 24 22:38:48 + 2007 --- I totally agree. Trying to insert a text object is a huge kludge. If text orientation (in a table, for example) can be rotated 90 degrees or 270 degrees, it makes perfect sense to have a 180 degree option. There have been numerous times I have needed to do this for making quizes, puzzles, forms, even table tents and cards (think- folding little cutouts in half). Trying to rotate lots of individual objects, all inserted in separate text boxes is a nightmare. So, like everyone else, I have to cheat and just use Draw- and lose the ability to have tables and other word-processing related functionality; or run the printed output back through the printer a second time. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 76364] Rotate table text 180 degr ees
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=76364 --- Additional comments from [EMAIL PROTECTED] Mon Apr 16 11:53:19 + 2007 --- You guys are really good at finding duplicates... I searched four different ways and still didn't find issue 29150. Perhaps it wasn't set to look that far back? Can't remember. Seems like most of the things I find, other people have found too. Let's hope we don't have to wait another three years before we see the enhancement or someone else finds it too! Thanks - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 76364] Rotate table text 180 degr ees
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=76364 --- Additional comments from [EMAIL PROTECTED] Sun Apr 15 11:17:52 + 2007 --- Yes, you can create create an object in Draw that is rotated and then insert it into the Writer document for each cell, but it is a royal pain in the ***. You end up with a document that is huge, messy, extremely complicated, hard to edit, style-hostile, and fragile. One can also rotate text 180 degrees in a spreadsheet. So Writer is the only one that artificially limits rotation to 0, 90, 270. Strange, no? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 76364] Rotate table text 180 degr ees
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=76364 Issue #|76364 Summary|Rotate table text 180 degrees Component|Word processor Version|OOo 2.2 Platform|All URL| OS/Version|All Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|ENHANCEMENT Priority|P3 Subcomponent|formatting Assigned to|mru Reported by|crxssi --- Additional comments from [EMAIL PROTECTED] Sat Apr 14 17:09:15 + 2007 --- On several occasions now I have needed to rotate text in certain table cells by 180 degrees (upside-down). There are options for 0, 90, and 270 in character-position now... why not 180? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 75218] Convert Case: Initial Caps
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=75218 --- Additional comments from [EMAIL PROTECTED] Thu Mar 8 13:20:24 + 2007 --- Oh- terribly sorry... I completely forgot I had already found and commented on an existing issue. Sometimes my memory is not what it used to be. I have no idea why it didn't come up when I searched before posting. But I do greatly resent your tone. Perhaps before judging what happened and verbally lashing me, you could 1) Realize that it could have been an honest mistake (which it was) 2) Realize that *I AM ALSO* a volunteer, trying to help make OpenOffice better, just like you. Thank you for volunteering your time. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 3395] Reveal formatting codes
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=3395 --- Additional comments from [EMAIL PROTECTED] Tue Jan 30 17:07:54 -0800 2007 --- Codes were the best thing ever, and it is what made WordPerfect one of the best word processors of all time. I still use it when possible, and it reminds me of the limitations of OpenOffice Writer. Codes allow the user much more power and contol over documents. They prevent mysterious documents- you can tell exactly what is happening. Even trying to determine which styles are in effect on something can be a challenge. This issue was opened almost five years ago and still marked as OOLater. Isn't it time to consider that now is later? OpenOffice is great, but it can always be better! - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sw-issues] [Issue 1601] Character/Case should suppo rt toggle case and First Letter Capitalized (T itle Case alike)
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=1601 --- Additional comments from [EMAIL PROTECTED] Wed Jan 17 06:54:55 -0800 2007 --- Six YEARS!!! That is how long people have been waiting for this relatively simple feature to be added to OpenOffice! I can't tell you how often I have needed the initial caps (first letter of each word) function. Anybody out there want to take this on? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 72829] Print shifting from older documents with trim option
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=72829 --- Additional comments from [EMAIL PROTECTED] Thu Dec 21 04:24:52 -0800 2006 --- jirkaz: Have you tried to replicate what I found, above? Open the old doc, change all the margins to be the same as default new documents, check printer options to make sure it says DEFAULT, then print it... - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[graphics-issues] [Issue 72829] Print shifting from older documents with trim option
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=72829 Issue #|72829 Summary|Print shifting from older documents with trim option Component|Drawing Version|OOo 2.1 Platform|All URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|printing Assigned to|wg Reported by|crxssi --- Additional comments from [EMAIL PROTECTED] Wed Dec 20 17:08:12 -0800 2006 --- This is a continuation of the supposedly fixed issue #70619. In OO 2.0.4, a NASTY bug was introduced into Draw that caused printed documents to shift down and to the right by about 1/4 each when printed. Well, at first glance, it was fixed in 2.1.0. But it is still there, in hiding. If you open an existing document (pre 2.1.0) that doesn't have margins set to .39 .39 .39 .39 (why did the default margins change in 2.1.0?), and try to print with DEFAULT mode (whatever that is), it will tell you page options don't match and do you want to trim or fit to page/etc. If you changed the margins on the old document to .39 before printing DEFAULT, it will ask no questions and print perfectly, the same as in older OO (pre 2.0.4) versions. However, if you say trim, it will NOT PRINT CORRECTLY, shifting the entire printed page down 1/4 and right 1/4 and moving the center point. I don't understand why the margins make any difference anyway, since they don't seem to serve ANY purpose in draw documents. (Besides- fit to page with printing is also misleading in function and in help- it doesn't do what the user expects: it doesn't scale EVERYTHING down to fit on one page, it just simply scales down .15 on all sides to compensate for the printer's unprintable zone. But that is a different issue.) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
