[framework-issues] [Issue 85661] Cannot paste (image) from clipboard copyed from .net
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=85661 --- Additional comments from stuartpresc...@openoffice.org Wed Jul 14 10:26:42 + 2010 --- As a work-around for those developing .NET applications who want to be able copy images to the clipboard and have OOo cope with this, try deliberately sticking a DIB on the clipboard instead (or as well as) the System.Drawing.Bitmap. e.g. the following code will allow you to place a system.drawing.bitmap bmp on the clipboard in an OOo-compliant fashion. Dim ms As New IO.MemoryStream() Dim ms2 As New IO.MemoryStream() bmp.Save(ms, System.Drawing.Imaging.ImageFormat.Bmp) Dim b() As Byte = ms.GetBuffer() ms2.Write(b, 14, CInt(ms.Length - 14)) ms.Position = 0 Dim dataObject As New DataObject() dataObject.SetData(DataFormats.Bitmap, bmp) dataObject.SetData(DataFormats.Dib, ms2) Clipboard.SetDataObject(dataObject, False) (Adapted from http://www.ureader.com/msg/14721255.aspx) - 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
[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 Mar 17 10:09:53 + 2008 --- Perhaps for screen vs print, the pixel/length selection could offer a description of the quality of the export as well as the absolute number of pixels per unit length. It could something like the following, thus giving the best of both worlds: ( ) Use resolution: Resolution value dropdown 72 pixel/inch (screen) 75 pixel/inch 96 pixel/inch 100 pixel/inch (typical LCD) 125 pixel/inch 150 pixel/inch (low quality print) 300 pixel/inch 600 pixel/inch (high quality print) As discoleo pointed out, 600 pixel/inch is probably actually an unachievable resolution, but I don't think that should stop it from being included (600 dpi is the standard resolution for BW printing by publishers IME). I would expect to be able to type into the box to choose my own resolution too if I had a particular requirement. (Combobox is the name that I know for such a widget, but I don't know what other names it goes by: a hybrid textbox/dropdown). A dropdown does seem more sensible for this than a set of radio buttons with a final option saying custom with a text box next to it. I would also expect that if I changed an option as to what units I wanted to work in, that each of the above values would be recalculated into the new units (i.e. the dialogue would show 28.3 pixel/cm where it used to show 72 pixel/inch). I would hope that the control of the units was actually on that dialogue box (as it is in Gimp, for example) to make it easy for me to switch between them, since all my drawings are done in metric and any web work is done in pixel/mm but printing work invariably involves dpi and requires that instead. - 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 Mar 17 23:47:56 + 2008 --- I'm glad to see that people are thinking a lot about this issue. @discoleo: In the meantime I strongly oppose DPI. As I said, I don't care about the semantics of this. Since pixel/length is what people normally are actually wanting, that is probably what should be actually used here (pixel/cm or pixel/inch). In Adobe Illustrator CS3, everything has been moved to the document creation dialog. Yuck. As someone who uses OOo Draw, this is the worst place to put it. This is an export setting not a document creation setting. Why implement something in 20+ dialogs, when one can have everything put logically in one place and control the whole document-creation process in a unitary way? Why does this have to be in 20+ dialogues? There is only one raster export dialogue and this is the only place it needs to be. As mentioned previously, CS3 seems to limit the PPI to only 3 values: - screen: 72 PPI - medium: 150 PPI - high: 300 PPI Again yuck. That is a complete pain in the backside and provides me with yet another reason not to use CS3. Please go back and read *carefully* the two use cases I posted earlier. You may not think they are valid because you do not work that way. The fact is that others do and so the interface should allow them to do so. Your interface suggestion would require me to export from OOo Draw at the highest possible resolution and then resize the image in some other drawing tool such as the gimp, or use some other intermediate file format as the conversion tool (e.g. odg = pdf = png). These extra steps are what we are trying to remove here. I bet 99% will watch at approx. 72 PPI. [And don't come with LCD monitors. These are a travesty as every professional user can witness.] My laptop has 110 dpi. I have not even seen a computer with less than 96dpi for a very long time, even on CRTs. LCDs are a reality and remember that OOo Draw is there to be used by mum and dad making graphics for their website as well as a professional user. As said, a 600 DPI Laser Printer actually prints at some 60-85 PPI (or [..] You have made your point. Please stop banging on about it. It's completely orthogonal to the question of being able to export the vector graphic at arbitrary resolutions. The feature request is not please allow me to export the graphic at resolutions for printing it is please allow me to export the graphic at arbitrary resolution. D.) COLOUR-SPACE This is also completely irrelevant to the current discussion. If you want colour space management in OOo Draw, then open a separate issue for it rather than confusing this one any further. And I can only urge you to watch again the Adobe Illustrator tutorial. I did and it confirmed why I don't like it and why OOo Draw can be a much better program. Now, I hope that everyone will understand why I insist on my previous solution. It is in the best interest of OOo and its users. I wholeheartedly disagree. Your suggestions are fantastic for some use cases -- in particular the ones that *you* use. At the same time, they are horrible for many other users and from seeing how drawing programs are used widely by non-professionals this is a real use case. Please do not tell other people that they way they work is wrong and that they need to be protected from themselves. Please at least do us the courtesy of trying to understand what we are asking for and work others' requirements into your schemes rather than just declaring that you are an expert in the field and that only your ideas matter. Your experience and expertise is valuable to the discussion; so is the experience usage patterns of other users. If you look carefully at the other suggestions that have been made for how to provide this feature, you will see that their suggestions will allow you to do you work and also allow me to do mine. That's whole lot more powerful than something that satisfies only you. - 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 16 23:55:24 + 2008 --- One thing that seems to have been missed in all this is that images in Draw fundamentally do have a size and it is measured in cm or inches as shown on the ruler that surrounds the image. All we are asking for is the ability to select how many pixels per unit length are saved into the raster image on export. Now, I quite like nmailhot's suggestions here as I think they encompass a few different use cases that I have personally seen and they don't seem to be well enunciated here yet: (1) A user has drawn a diagram in Draw. A publisher specifies that the diagram must be 8.25cm wide so the drawing is this size. The publisher then says that they would really rather a TIFF than any other form of diagram so please provide the diagram at 300dpi meaning 974px wide. (discoleo: I'm not making this up... you may have more experience of preprint stuff than others here, but these are instructions to authors from publishers) (2) The user then wants to put this same diagram on their web page. They know that the rest of their graphics and their web page layout are set up for 400px wide so they then want to export a graphic at that size. Please note that I have been able to talk about these things without mentioning loaded terms such as resolution or dpi. As a user, I truly don't care about whether you call them lpi dpi ppi or anything else you may care to mention. In fact, I'd probably prefer that you scrapped all of those terms and gave me the option to specify how the export was performed in pixel/inch, pixel/cm and perhaps throw in some others that might be useful such as pixel/mm and pixel/pt. (since the experts apparently can't agree on what terms like dpi means and some experts here are arguing that the rest of the world's current usage is wrong and that they are right...) Thinking through the different suggestions that have been offered here, I have tried to distil what, in my mind at least, is the difference between the ideas that I like and those that I dislike. One thing that jumped out at me was that discoleo's mockup and suggestions are heavily influenced by what he declares to be his workflow: In general, when I (or a user) create a work, I will have to decide beforehand, what is the purpose of this work: A.) Display it on screen B.) Print it This workflow is the opposite of what normally happens in my experience. You end up using the same graphic or perhaps a derived graphic in both print and on screen and you need to be able to export an image from Draw at any stage. Throwing words around like pragmatic and telling us that users need to be protected from themselves doesn't help here. Providing a user interface that is sufficiently flexible to fit the user's preferred workflow does help. I'm almost feeling that the more discoleo argues about this bug, the more he is arguing against this feature even been useful, which to me means that he doesn't understand the use cases for it. In particular, the insistence on using pragmatic pixel/inch values is problematic as it makes use case 2 impossible to fulfil. On the other hand, the interface suggested by nmailhot allows the user to choose how the export should be performed in a variety of different ways. The user can choose either the size in pixels or the pixels/cm (or inch etc) which gives us the ability to pass use cases 1 and 2 that I have highlighted. However, I would suggest that the screen vs print resolution could be collapsed into just one dropdown to make the interface simpler. Additionally, the ability to export at different page sizes seems orthogonal to the raster export and instead a feature that should be on a vector export dialogue box. Final comments -- nmailhot suggested this little gem in the export interface: ( ) Selected (o) Visible area ( ) Whole page YES PLEASE!! That would be fantastic. I spend too much time resizing the page down to the graphic size (often by trial and error) so that I can export to PDF only the image and not the surrounding whitespace. (These PDFs are usually fed into pdflatex as graphics). Also, just to pick nits... discoleo wrote However, pixels have NO dimension. That is true up to the point where a resolution header is inserted in the image and is quite common in many raster image formats. I struggle to see how this comment (along with much of discoleo's lecture series on printers and dots) has anything to do with how to allow the user to change the number of pixels exported by 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
[sc-issues] [Issue 3997] Flexible source ranges - Ad d option, to select x-values for different y- values / columns separately
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=3997 --- Additional comments from [EMAIL PROTECTED] Thu Oct 18 13:26:52 + 2007 --- I've just tried OOo 2.3 and the new plotting component is fantastic! It works wonderfully! At last, I can recommend Calc to people at work as a viable alternative for routine data processing. This is a big milestone for Ooo. Thank you very very much! - 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]
[sc-issues] [Issue 72325] Cannot specify which oo co mponent should open file from command line
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=72325 Issue #|72325 Summary|Cannot specify which oo component should open file fro |m command line Component|Spreadsheet Version|OOo 2.0.4 Platform|All URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|open-import Assigned to|spreadsheet Reported by|stuartprescott --- Additional comments from [EMAIL PROTECTED] Wed Dec 6 08:05:45 -0800 2006 --- I have a series of data files generated by other software. They variously have .txt, .dat and .csv extensions. From the command line, there is no way of specifying what component of openoffice will open the file. The .csv file automatically opens in calc (which is what I want) but the other files are opened not by calc but by writer. Can you please offer a command line switch to specify which component the data should be opened in? Or use the name underwhich soffice was invoked as a hint (i.e. if I run oocalc file.dat, I obviously don't want to open the file in oowriter, do I?) - 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]
[sc-issues] [Issue 72330] Have to specify which oo c omponent file should open in every time
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=72330 Issue #|72330 Summary|Have to specify which oo component file should open in | every time Component|Spreadsheet Version|OOo 2.0.4 Platform|All URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|open-import Assigned to|spreadsheet Reported by|stuartprescott --- Additional comments from [EMAIL PROTECTED] Wed Dec 6 09:15:14 -0800 2006 --- I have a series of data files generated by other software. They variously have .txt, .dat and .csv extensions. Within the oocalc user interface, I have to specify, *every time* that I want to open the .dat and .txt file in oocalc and not in oowriter. This is a pain, especially when there are a lot of files to import and process. In fact, this makes OOo almost unusable for me. To add insult to injury, the user interface for selecting that the file should be opened in calc is quite bad from a usability perspective. Selecting an item from a very long dropdown list is probably the least user-friendly way of doing this. Perhap you can create a new menu item Open a file in this component? Or a checkbox on the Open dialogue box saying Open the file in the same component? - 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]
[sc-issues] [Issue 72325] Cannot specify which oo co mponent should open file from command line
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=72325 --- Additional comments from [EMAIL PROTECTED] Wed Dec 6 09:32:31 -0800 2006 --- Rereads man page in debian packageshakes head... Will file that as a bug against the debian man-page instead :) Thanks for the tip! (PS perhaps soffice should complain about unrecognised command line options rather than just ignoring them?) - 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]
[sc-issues] [Issue 34078] Enhancement of CSV import , i.e. with fixed format files (no field delim itter) leading and trailing spaces should be a utomatically eliminated like in Excel. Also op ening
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=34078 --- Additional comments from [EMAIL PROTECTED] Tue Mar 21 10:29:49 -0800 2006 --- I think there's a problem with the way this bug has been written up... there are two things involved: 1/ how spaces are handled and 2/ opening a .txt file in oocalc should suddenly start oowriter for that file. I've just spent a *very* frustrating afternoon analysing data. It wasn't frustrating because of the quality of the data but the way that I had to go File - Open then select the file I wanted then scroll down a *long* list of formats to find csv/txt *every* time I opened a file. Guess what... the novelty of that sure wore off pretty quickly. As much as I hate to admit it... it would have been easier and faster with M$Excel where I could have just done a drag+drop onto excel and it would have opened the file in excel and *not* in word just because it was a .txt file. So... ooo devs: how do we go about convincing you that this feature is a huge PITA? - 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]
[sc-issues] [Issue 34078] Enhancement of CSV import , i.e. with fixed format files (no field delim itter) leading and trailing spaces should be a utomatically eliminated like in Excel. Also op ening a .TXT file in Calc should not automatic ally bring up Writer.
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=34078 --- Additional comments from [EMAIL PROTECTED] Mon Jun 20 22:08:55 -0700 2005 --- I think this issue is less about whether OOo *can* import a TXT file or not than it is a design issue that OOo ignores the current state of the application in deciding *how* to import it. For example (under OOo 1.1.3 (Debian Sarge)): The simple attachment will open in OOo Calc if and only if I select Tab Delimited as the import filter, even though I am already editing OOo Calc. If that import option is not selected, it opens it in Writer. But if I have to import 100 tab-delimited files like this, I don't want to have to scroll all the way down to the tab delimited entry (which is helpfully called Text CSV... h?) for *every* file. It would be much nicer for OOo to say I'm currently running Calc, so I'll open this new file in Calc if possible. Even just a persistent checkbox in the open dialogue box to enable this feature would be wonderful... (you could be more clever than that and use a regexp against the file to see if it looks like CSV or TSV, but allowing *easy* override of these default behaviours is important) This is a big barrier to me doing anything serious with Calc (well, that and the graphing component is hopeless, see http://www.openoffice.org/issues/show_bug.cgi?id=3997 for more on that!). Until I can easily import lots of data files from scientific instruments (and then graph them!) Calc will only be a toy for me. - 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]
[sc-issues] [Issue 34078] Enhancement of CSV import , i.e. with fixed format files (no field delim itter) leading and trailing spaces should be a utomatically eliminated like in Excel. Also op ening a .TXT file in Calc should not automatic ally bring up Writer.
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=34078 --- Additional comments from [EMAIL PROTECTED] Mon Jun 20 22:09:14 -0700 2005 --- I think this issue is less about whether OOo *can* import a TXT file or not than it is a design issue that OOo ignores the current state of the application in deciding *how* to import it. For example (under OOo 1.1.3 (Debian Sarge)): The simple attachment will open in OOo Calc if and only if I select Tab Delimited as the import filter, even though I am already editing OOo Calc. If that import option is not selected, it opens it in Writer. But if I have to import 100 tab-delimited files like this, I don't want to have to scroll all the way down to the tab delimited entry (which is helpfully called Text CSV... h?) for *every* file. It would be much nicer for OOo to say I'm currently running Calc, so I'll open this new file in Calc if possible. Even just a persistent checkbox in the open dialogue box to enable this feature would be wonderful... (you could be more clever than that and use a regexp against the file to see if it looks like CSV or TSV, but allowing *easy* override of these default behaviours is important) This is a big barrier to me doing anything serious with Calc (well, that and the graphing component is hopeless, see http://www.openoffice.org/issues/show_bug.cgi?id=3997 for more on that!). Until I can easily import lots of data files from scientific instruments (and then graph them!) Calc will only be a toy for me. (This is perhaps an associated issue... if I run oocalc testcase.txt where the file is tab delimited, it opens in Writer not 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-issues] [Issue 34078] Enhancement of CSV import , i.e. with fixed format files (no field delim itter) leading and trailing spaces should be a utomatically eliminated like in Excel. Also op ening a .TXT file in Calc should not automatic ally bring up Writer.
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=34078 User stuartprescott changed the following: What|Old value |New value Attachment data| |Created an attachment | |(id=27360) tab delimited | |text file that is openned | |by oocalc in writer --- Additional comments from [EMAIL PROTECTED] Mon Jun 20 22:10:44 -0700 2005 --- Created an attachment (id=27360) tab delimited text file that is openned by oocalc in writer - 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]
