Apache OpenOffice (AOO) Bugzilla – Issue 4499
Export to bitmap file has fixed DPI (resolution)
Last modified: 2019-10-05 13:44:24 UTC
When exporting graphics (Draw or Impress) to a bitmap file (BMP, TIFF, JPG, GIF, PNG) DPI resolution is fixed at approximately 90 DPI regardless of options selected. BMP export filter has resolution option, yet selecting different DPI levels has no effect on saved file. Other filters don't provide option, therefore this might be an enhancement?
Wolfram should take care of it.
I have tested this on version 1.0 and selecting different resolutions has an effect. Please send a step by step description what you are doing. Thanks in advance.
Tested this again, no problems with the resolution. Due to a lack of further information I close this issue.
Works for me.
Closed.
Sorry for delay. Details: When saving BMP bitmap, specifying DPI will only set the "DPI description" in BMP file, if will not actually save the vector graphics to a bitmap at that resolution. It seems that all exported bitmaps are saved at 97 DPI in OpenOffice regardless of file format (JPG, PNG, TIF, etc...) Example: Open Draw. Create one object, size: 1 inch by 1 inch. Select it, export it (selection) as a BMP specifying a DPI of 300. If you look at the raw saved .BMP file, you will notice that the actual pixel resolution of the image is only 97 pixels by 97 pixels, when it should be 300 by 300. Regarless of selected DPI, actual pixel resolution is always the same: 97 DPI. It would be very useful to be able to specify a target resolution when saving to bitmap, otherwise it's use is very limited. Using OpenOffice v1.0 under WinXP Pro. Thanks.
Yes, thanks, now I can reproduce it. Reassigned to Sven.
Our current behaviour is absolutely correct, it specifies the logical size for a fixed pixel size which gives a DPI value based on the logical display size. But on the other hand, I think resampling of the image itself or creating the bitmap with other pixel sizes is also very useful. I will take care of this new feature.
Thanks. I may not understand what you are saying about logical sizes and where this is used, but normally DPI means "Dots Per Inch". If I export an object as a .BMP from OpenOffice with a DPI of 600 and load that .BMP into a professional software package or even OpenOffice, the object will be a small fraction of the size it should be. This is simply because the software reads from the file that it is 600 DPI, therefore sizes the image accordingly, but the actual DPI is 96... the software has no way of knowing the "logical"? size. So 1 inch in the source becomes 0.16 inch in the target. I don't mean to press the issue, but I don't see this behavior as "absolutely correct". A curve (spline) or circle exported to a bitmap at a fixed 96 DPI is only generally useful on a display monitor. For print work, much higher DPIs are required to avoid seeing all of the blocky pixels that compose the curves. I realize you know this, I just though I'd point out the usefulness. Thanks for taking care of it!
This is something I've been missing for a very long time in the OpenOffice.org Draw. I hope this will be implemented soon. Also this isn't only Windows XP issue.
Up from version srx644 it is possible via api (com::sun::star::drawing::UnoGraphicExporter) to export graphics in a special pixel resolution, a basic macro will be able to take advance of this new service. SJ->BH: We need a new UI for the filter dialogs, can you please promote this new feature, it is really necessary.
I'd like to see this issue enhanced too. I do a lot of drawing in Draw for images I later upload to sites such as cafepress.com to use on shirts, posters, etc. However, cafepress.com has specific requirements for its images, usually a combination of size (e.g. image has to be 8 x 10 inches), as well as minimum DPI (usually 150 or 200). After I export the drawing to PNG format I have to later open it in another program like PhotoShop or Irfanview to manually resize it and change the DPI resolution. being able to control that right out from openoffice.org Draw would be a godsend.
*** Issue 13396 has been marked as a duplicate of this issue. ***
*** Issue 17678 has been marked as a duplicate of this issue. ***
*** Issue 12881 has been marked as a duplicate of this issue. ***
What is the target milestone on this issue?
I am concerned with a related issue, but not identical to this discussion thread. That is, how are graphics that are originally bitmaps handled, photos in particular. This thread seems more concerned with conversion of object graphics to bitmaps. I am concerned with being able to control quality (using jpeg and pdf mostly). At one end, I want to assure no loss in quality but maximal lossless compression and at the other end, small files with quality suited to display on a monitor. At the high quality end I want preservation of the original quality. I don't want up or down sampling, but I do want the best lossless compression available as in jpeg. From this discussion, I get the idea that this might not be happening currently. Thanks Dave Auslander, dma@me.berkeley.edu
To continue the photo/JPEG discussion --- I loaded a photo into OO-Draw. The original's resolution was 2560x1920. Without doing anything to the image, I then asked OO-Draw to export it as JPEG with the quality option set at maximum (100). The resulting JPEG file had a resolution of 816x1056. DRAW is clearly resampling/resizing the image to some internal drummer. To control quality, I need to be able to specify resolution as well as compression for JPEG files. Thanks Dave Auslander dma@me.berkeley.edu
I believe that when an image is imported into draw it is constrained by the margins of the document using screen resolution. Though I don't like this either, it may explain the apparent resampling.
*** Issue 9192 has been marked as a duplicate of this issue. ***
Using OOo 1.1 I tried to use the update API as Sven Jacobi described on 2002-12-05 08:35 PST via StarBasic. After digging into the UNO/Basic-Binding (a mess to figure out btw! although it is described in http://api.openoffice.org/docs/DevelopersGuide/ProfUNO/ProfUNO.htm 3.4.3 - but having to excessively use .Dbg_* is annoying) I could not find a reference how to set the resolution. I can now export programmatically to a bitmap file but I still don't know how to have the file being created with more "detail". Is this API update present in OOo 1.1 at all? If it is I could post the macro here.
The same issue is present in openoffice 1.1 under debian. Could someone clearly define the terms logical size, fixed pixel size and logical display size? It doesn't make much sense using these terms without a proper definition. Maybe then I could understand why ooDraw exports bitmaps absolutly correct? That's not clear to me.
If I have only one horizontal line in Draw (thinkness 0inch - hariline) that is 1inch long and I export this to a bitmap and set 300 dots per inch, then I expect to get an bitmap that is 300 dots wide and 1 dot high. Because we have a clear length description with the paper size in Draw, this should be the root for a "dots per inch" calculation. If I print out the one line bitmap on a laser with 300dpi resolution this line should be 1inch in size. So we have a "logical not pixeled" size of 1inch for the line and a "pixel size" of 300 pixels when exported to a bitmap with 300dpi.
I have made some progress in this issue. I have exported my drawing as a PDF. I then used Multivalent (http://www.cs.berkeley.edu/~phelps/Multivalent/ ) to create a java program to convert the PDF into a high quality TIFF. I slightly modified the doc.tools.PageImage to zoom the document. However, I aimed at a resolution of 600 dpi but only scored 480 dpi (which was fine for the job!) so I haven't quite understood the API yet. If I need to do it often, I think I will write a java plug in (or some such) which prompts for resolution, exports the file as a temporary PDF, creates the image and deletes the PDF. Anyone think this is a good approach, or have a better idea?
This is a workaround for advanced users that has been available all the time. Not to say this would not be a good idea, but is no progress towards the original problem/feature request. You can always create a PDF and use for example ghostscript (which can be scripted) to render a bitmap in any desired resolution. I have done this for an ancient fax application to print PS to it and have gs convert to CCITT G3 TIFF years before. This is not what the user desires. If he wants to have his 2 inch x 2 inch graphical element exported at 600dpi, he hopes to get a bitmap of 1200x1200 pixels, if at all possible with or without anti-aliasing and in a color depth requested. This lacking feature still keeps me from a) using OOo for graphics-intensive work and b) integrating OOo Draw into another application for half-automatic page generation for photo albums. [b) would require the export feature to also create good quality, e.g. anti-aliasing, very good image resizing algorithm]
*** Issue 10662 has been marked as a duplicate of this issue. ***
The workaround of exporting to a PDF then using Ghostview to render that image at a given resolution will work to some extent, here is an example for 300dpi output to a 16million color PNG format: gs -sDEVICE=png16m -r300x300 -sOutputFile=my.png my.pdf To list gs devices use gs --help Two things that need to be implemented tested if this is added as a feature are: 1) resampling bitmaps, for example as used in area fill, so that they still render at the scale of the original document. 2) an anti-aliasing option. You can create an anti-aliased image at say 300dpi by doing the following: 1) export from OO to pdf 2) Use gs to create a png16m raster image at, say, 600 dpi 3) Use gimp or imagemagick to rescale the 600dpi image to half size. The downscaling process will apply quite effective antialiasing. I've been able to generate reasonably good images using this technique.
Summary: Enable resampling images at export.
*** Issue 32216 has been marked as a duplicate of this issue. ***
I don't understand why this issue is targeted "OOo Later"? This target milestone assignment basically means that the first OOo version that people will consider for creating high quality bitmap images will be a hypothetical "later" version and not version 2.0. The amount of duplicates to this issue shows how important correct handling of bitmap export is to many users, including myself. Clearly the described problem is not an ENHANCEMENT but rather a DEFECT - and no small one at that - in the OOo Draw export filters. An enhancement in my book is making a working function better whereas bitmap export in Draw isn't a working function with respect to the users' expectations. Several people already stated that they expect proper handling of dpi/size values and resampling from bitmap export, a functionality that every decent image editing software offers. The offered workarounds are good for experts (that is, they work, which doesn't say they are a convenient/efficient way to create bitmaps!) but "normal users" won't be able use them.
I came accross a OO-Basic macro that allow JPEG export of OO-Draw documents at user-definable resolution. I'll attach it to this issue. I've tested the macro and it really works! You can set both pixel resolution and 'logical' resolution. Why isn't this functionality exposed in the user-interface ?????????????? This is a crucial feature for any vector-drawing application. This proves that no major internal reworking of the graphics system is required to make this work. There's no excuse now ... The BMP export filter has GUI-elements for setting the resolution but these are broken. The other raster formats (PNG/JPEG/TIFF etc.) have no such options. I got the macro from "Andrew Pitonyak's Useful Macro Information" BTW.
Created attachment 23854 [details] OO-Basic macro for exporting a Draw document at a definable resolution
*** Issue 51421 has been marked as a duplicate of this issue. ***
*** Issue 25536 has been marked as a duplicate of this issue. ***
*** Issue 29471 has been marked as a duplicate of this issue. ***
Here are a lot of questions regarding why this function has not already been integrated into the user interface. I was able to change the core to support a definable resolution, but each change within the UI requires a specification and due to limited resources I was not able to create one. We have also take into account that each filter is having its own user interface and therefore it requires much work to implement this feature. So I would prefer a more general solution, maybe a two tabbed dialog where the first tab provides general functionality, and a second tab providing the filter dependent settings, such as compression, interlace and or a preview graphic. This also ensures that the graphic filter UI is getting a well-defined look & feel regardless of which filter is used. Anybody can help by providing proposals or by working out the full specification, which is half of the work. Till then the only way to create bitmaps with definable resolution is to use the macro Bryan mentioned. I initially created this macro to bypass the resolution problem, the macro can also be found on: http://codesnippets.services.openoffice.org/Office/Office.GraphicExport.snip
ANTIALIASING could also be useful in output. OpenOffice does beautiful antialiasing to screen, and then when saving to file we get something few classes lower quality. Currently I am forced to do "finish" with Adobe Illustrator, even though I prefer OpenOffice Draw as more configurable and customizable. Keep up the good work anyway! Marvin
*** Issue 63082 has been marked as a duplicate of this issue. ***
Yes, please please add the antialiasing! antialiasing antialiasing antialiasing !!! It is much more important for me than the resolution itself. Currently I am forced to do weird stuff like: - export the drawing to PDF - display the PDF in 100% on my screen (Adobe Acrobat does the dirty antialiasing work) - press Print Screen to save the screen to clipboard - paste to a bitmap software How humiliating!
*** Issue 66029 has been marked as a duplicate of this issue. ***
I have the same problem with PNG exports
Please make the export make work as one would expect intuitively. Just setting DPI without scaling the image is not enough. Anti-aliasing would also be great, although this could be simulated by exporting a drawing with a high DPI setting and bicubic downscaling with another software.
I, too, have been waiting years for this issue to be addressed. All raster exports should ask for DPI so you can control the resolution of the output. And Anti-aliasing the output would be a wonderful (although possibly complex) bonus.
Interoperability with other programs and other users is important. Therefore bitmap export is very important. For instance, I use OOo Draw for company logos. Frequently a printer needs a bitmap version of the logo. The ability to export a good quality bitmap is really absolutely essential. We do need this facility.
The export filters (Graphics export) are not saving the DPI setting in the final image file header. PLEASE HELP! Although I am using ImageMagik to fix the resolution setting in the image, I want to be able to do this from my macro. (Please note...All my graphics are the same size...so this macro works) This is an export from Draw Macro: ----------------------------- Dim aFilterData (10) as new com.sun.star.beans.PropertyValue aFilterData(0).Name = "PixelWidth" aFilterData(0).Value = 3307 aFilterData(1).Name = "PixelHeight" aFilterData(1).Value = 2336 aFilterData(2).Name = "LogicalWidth" aFilterData(2).Value = 140 aFilterData(3).Name = "LogicalHeight" aFilterData(3).Value = 98.89 aFilterData(4).Name = "Quality" aFilterData(4).Value = 80 aFilterData(5).Name = "ColorMode" aFilterData(5).Value = 0 aFilterData(6).Name = "ExportMode" aFilterData(6).Value = 1 aFilterData(7).Name = "Resolution" aFilterData(7).Value = 600 xDoc = thiscomponent xView = xDoc.currentController xSelection = xView.selection If isEmpty( xSelection ) then xObj = xView.currentPage else xObj = xSelection End If xExporter = createUnoService( "com.sun.star.drawing.GraphicExportFilter" ) xExporter.SetSourceDocument( xObject ) Dim aArgs (2) as new com.sun.star.beans.PropertyValue Dim aURL as new com.sun.star.util.URL aURL.complete = 'myfile.jpg' aArgs(0).Name = "MediaType" aArgs(0).Value = "image/jpeg" aArgs(1).Name = "URL" aArgs(1).Value = sFileUrl aArgs(2).Name = "FilterData" aArgs(2).Value = aFilterData xExporter.filter( aArgs() ) -------------------------- Macro ends. This macro produces the image in the correct size, but the DPI is wrong. The lines aFilterData(7).Name = "Resolution" aFilterData(7).Value = 600 Should be telling the export filter to set the DPI setting in the image header. But it is not. This appears in OpenOffice 2.0 and 2.1. And seems to be common in all the Image export filters (not just jpeg). Is this going to be fixed?
I think this is important. No promises but I try to do something for 2.3 here
Created attachment 49920 [details] ImgeExportAtCustomDPI
Custom DPI choise at export will be great. I want share macro "image_export.bas" (based on bryancole example) that i write to solve this issue for my. Macro exports whole page or selection to current document directory with name as current document name with changed extension. Before exporting dialog shows exporting info. Image type and DPI can be set in macro source. P.S. Sorry for my terrible English
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.)
Dear developers, please change OS to "All". And one more question: is it an ENHANCEMENT, but not a DEFECT?
Great to hear it's been fixed. It would be even greater to know how it had been fixed. Is it by the availability macros. In which case it needs signposting and explaining? A little guidance would be greatly appreciated.
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.
*** Issue 27919 has been marked as a duplicate of this issue. ***
Discovering the poor export resolution was a major disappointment after putting about 50 hours into a drawing. For that I got a 96 dpi tiff file -- same thing in a png file, and a gif file. Obviously I spent some time trying to figure out how to fanagle even a "draft" quality resolution of 300 dpi. This makes the application suitable for exporting web graphics only. It is not suitable for generating exports of bitmap print graphics. Yes, you can print directly or pdf a file with cleaner output, but you can't export to a print quality bitmap format. This is a critical issue for a graphics program -- all the feature bells and whistles are pointless if you don't have a usable output. Draw is basically a screen etch-a-sketch as it stands now since it lacks normal graphics export functions. Sure a lot of file formats are supported. But anywhere off a monitor, the files themselves look like a 1980 dot matrix printout. I guess Draw is useful for making screen presentations (Impress), web page graphics, and screen icons, but it's not the *document* level graphics program it ought to be. You can pretty much do screen resolution graphics in any bit painter, including old MSPaint. Why bother with vectors at 96 dpi? Fix this one issue and you have a fine document graphics suite. Without it, you're painting with your elbows. This ought to be priority one.
retarget
So, it's now "retargeted" from some future version 3.0 to 3.1. 6 years since this was first brought up in version 1.0. What does the word "targeted" actually mean in a case like this?
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.
Thank you for the clarification. Re. votes: This specific issue has 45 votes, however other issues have been closed as duplicates of this one for example, issues number: 13396 17678 12881 9192 10662 32216 51421 25536 29471 63082 66029 27919 It is hard to imagine that for 6 years and innumerable OO versions, requests across multiple issues regarding this problem have not resulted in a change, unless there is a specific reason or policy at work. If so, it would be helpful to understand what that is -- at the very least it would stop wasting the time of those who continually attempt to describe and log it.
Please look again what sj has said(desc 37, 2005-11-01), especially,"Anybody can help by providing proposals or by working out the full specification, which is half of the work." You will find a template for a specification in http://wiki.services.openoffice.org/wiki/Specification_Template
Thank you regina, that is a very positive suggestion. I looked at the macro, but don't understand it well enough to know whether it is something I as a user could use to provide a workaround for obtaining higher resolutions than 96 dpi on bitmap file exports. Or how to implement it if it is useful. I also looked at the specification requirements, and it seems to say that I would need to have lined up a developer and QA person. Since I'm not a part of the OO organization, I don't know how to do that, but am willing to do whatever is needed. You also mentioned a proposal -- is there a link to a similar form or a description of what format that would take? I have thought carefully about how to simplify implementing the minimum necessary to increase resolution beyond the present 96 DPI. At present, there is a user workaround in OODraw which involves specifying an abnormally large page size, in order to increase the drawing resolution artificially before saving it. Since that method works the same in all filter types, its action is global. A software solution which essentially does the same thing under cover, except that the user interface now does the multiplication internally and correctly via a "DPI" (or DPmm) input field would seem to work across all filter types as well. The place to input this "DPI/DPmm" field might well be in the Format toolbar dropdown list, with an entry for "Export Resolution". It is a format variable, after all, for the document, This would mean that the individual filter dialogs would not have to be re-written. The user merely changes the resolution figure as a document format. I would be happy to write this up wherever appropriate -- I'm just not sure where or how to do his. Thank you for suggesting this way of dealing with this issue.
You can start with the template http://specs.openoffice.org/collaterals/template/2.0/OpenOffice-org-Specification-Template.ott (see http://specs.openoffice.org/) You need not worry about developers and so on, but fill in your proposals and leave blank the rest. Then you contact the mailing list discuss@ux.openoffice.org (see http://ux.openoffice.org/). You will get advise what to do next. I think your proposals will likely be discussed there directly otherwise you will be point to an appropriate place.
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
Thank you Regina, I'll do that. Thank you crxssi, I believe the place to address additional proposals would be in the discussion of a proposed specification. However, before you oppose what I'm suggesting, I hope you'll help. Let me ask you to consider the following: Issues surrounding the topic of low export resolution (96 DPI) have languished for 6 years now apparently because of the complexity of attempting to write specifications for each of the user filter dialogs. It has also been complicated by lumping together (if there are indeed 4 separate issues here) different user feature requests under one blanket issue number. That makes it extremely hard (if not impossible) to resolve or even describe. You can't pleas all of the people all of the time. If that make-it-do-everything approach is continued we may never see any change simply because other issues are more clearly defined and simpler to solve. First rule of support prioritizing -- knock the easy ones off the list first. Yes there are a lot of things on the wishlist. But frankly, I would be happy if I could simply export my drawings in a single bitmap file format at a reasonable resolution. ANYTHING to get a drawing into another program, like GIMP for processing with non-vector tools (airbrush, etc) would be fine by me. Such a clear and simple goal seems achievable IF we stop demanding a wedding cake and realize we can at least have a muffin. We've got nothing right now. 96 DPI is it. We're starving. Let's work together to get a preliminary simple decent quality export function going, and then add refinements later. At least then we can do real work in the program instead of waiting an unspecified number of years to use OODraw for anything but screen graphics and .pdf's. To me, OODraw and an export to a bitmap editor would represent the ideal in combined flexibility. The vector program allows the development and maintenance of the primary image in unlimited resolution quality; the bitmap editor, the ability to work with an instance of the image to do final hand airbrush level alterations to shading etc that are not possible in the vector program. These two kinds of programs should be able to work together. Neither is sufficient unto itself. We need both. I think if we insist on having every file filter dialog altered to include resolution, we'll never see it accomplished. New file filters are published or modified every year, the requests for additional filter input variables will be encouraged by doing it that way, and frankly the limitations on manpower probably can not be distracted in this vector graphics program to continual work on individual bitmap filter requirements. A global export resolution setting variable in a convenient place (NOT Options) for rapid alteration as needed would serve to greatly increase the utility of this program. And yes DPI is useful. Yes it is print oriented. That's what we're talking about here, print quality graphics -- the program already outputs screen quality graphics at 96DPI. All printers use this convention for resolution. And so do all bitmap editors. Since the document size is set in Open office it is perfectly straightforward to derrive total number of pixels from resolution and physical document size if it is important to you. Most people do not need it (except for screen graphics), but do understand, conceptually and visually, what resolution is, what the physical size of a document or image is and what they want to see for quality in that image. In fact a pixel is non-dimensional and by itself meaningless -- how big are 200 pixels and how fine a resolution is it? Anyway, if the developers want they can include both total pixel and DPI (or DPcm) in any way, just as long as I can create images which are exported at 600 dpi or better. That alone would vastly improve what can be done with Draw, agreed?
Thank you Regina, I'll do that. Thank you crxssi, I believe the place to address additional proposals would be in the discussion of a proposed specification. However, before you oppose what I'm suggesting, I hope you'll help. Let me ask you to consider the following: Issues surrounding the topic of low export resolution (96 DPI) have languished for 6 years now apparently because of the complexity of attempting to write specifications for each of the user filter dialogs. It has also been complicated by lumping together (if there are indeed 4 separate issues here) different user feature requests under one blanket issue number. That makes it extremely hard (if not impossible) to resolve or even describe. You can't pleas all of the people all of the time. If that make-it-do-everything approach is continued we may never see any change simply because other issues are more clearly defined and simpler to solve. First rule of support prioritizing -- knock the easy ones off the list first. Yes there are a lot of things on the wishlist. But frankly, I would be happy if I could simply export my drawings in a single bitmap file format at a reasonable resolution. ANYTHING to get a drawing into another program, like GIMP for processing with non-vector tools (airbrush, etc) would be fine by me. Such a clear and simple goal seems achievable IF we stop demanding a wedding cake and realize we can at least have a muffin. We've got nothing right now. 96 DPI is it. We're starving. Let's work together to get a preliminary simple decent quality export function going, and then add refinements later. At least then we can do real work in the program instead of waiting an unspecified number of years to use OODraw for anything but screen graphics and .pdf's. To me, OODraw and an export to a bitmap editor would represent the ideal in combined flexibility. The vector program allows the development and maintenance of the primary image in unlimited resolution quality; the bitmap editor, the ability to work with an instance of the image to do final hand airbrush level alterations to shading etc that are not possible in the vector program. These two kinds of programs should be able to work together. Neither is sufficient unto itself. We need both. I think if we insist on having every file filter dialog altered to include resolution, we'll never see it accomplished. New file filters are published or modified every year, the requests for additional filter input variables will be encouraged by doing it that way, and frankly the limitations on manpower probably can not be distracted in this vector graphics program to continual work on individual bitmap filter requirements. A global export resolution setting variable in a convenient place (NOT Options) for rapid alteration as needed would serve to greatly increase the utility of this program. And yes DPI is useful. Yes it is print oriented. That's what we're talking about here, print quality graphics -- the program already outputs screen quality graphics at 96DPI. All printers use this convention for resolution. And so do all bitmap editors. Since the document size is set in Open office it is perfectly straightforward to derrive total number of pixels from resolution and physical document size if it is important to you. Most people do not need it (except for screen graphics), but do understand, conceptually and visually, what resolution is, what the physical size of a document or image is and what they want to see for quality in that image. In fact a pixel is non-dimensional and by itself meaningless -- how big are 200 pixels and how fine a resolution is it? There is no answer to that. Of course it can be DPcm or whatever instead of DPI, as long as it's a ratio specifying resolution, and we can go at least as high as 600 DPI on a letter size document, I'll be happy. I realize that isn't photo editing quality, but there are plenty of photo editors out there, and no point in bitmap editing photos in a vector drawing program. There is however a critical need for exporting drawings created in a vector program into a bitmap editor for specialized processing unavailable in vector systems.
sorry about the double post, the browser hung on "contacting OOorg" and I refreshed and sent again. apologies
I share vtdiy's view on this so I wont restate what he's just said. I will point out that an intermediate solution would be to make an OOo Extension for this. With the functionality already in the OOo API, this is a relatively straightforward task of defining an export dialog in the Dialog editor and hooking it up to the high-resolution-export Basic macro, then adding a toolbar/menu item to activate it. The OOo integration with the Extensions repository makes is fairly easy to find and install enxtensions, so this is a much better solution than saying "hey, edit and run this macro", and no specification is required. Previously when I've attempted to make extensions, I've always failed when I tried to package it up (figuring out the addons.xcu file is hard), however there is now an "Addons Builder" extension which should simplify this. Next time I'm in the mood, I may try this (but don't hold your breath as I've many other things higher up on my todo list!)
As a developer I like to further emphasis e that any help from none developers is welcome. You do not need to be a developer to do a specification. A formal specification using the templates already mention would be best. But you could also draw a dialog on a sheet of paper using a pencil, scan it and post it for discussion. Please do not respond by "but it is so clear what the requirements are, I do not see why I have to write a specification". Reading the latest comments it looks to me that there is still room for discussion what different people expect from this feature. For me as a developer, if I have a specification that clearly tells me what is wanted where I do not need to spend additional time to gather the requirements myself is something that is more likely to be implemented than an issue without a specification. There is still time to do this for OOo 3.0 with an extension, so any work from your side is welcome and may speed things up.
I have written a specification and contacted the ux mailing list. Haven't heard anything back yet, but perhaps it is the time difference. I'm not sure where to put the specification or how to upload it.
Hi all, this issue has 45 votes and a bunch of cc people. Yet less than 5 people help with the feature specification on the ux discuss list.
The location for the current discussion is: http://ux.openoffice.org/servlets/BrowseList?listName=discuss&by=date
I have been trying to come up with workarounds. This morning I worked on ghostscript command lines for conversion of an OODraw .pdf file to a bitmap format at specified resolutions. The following ghostscript command line example will do the conversion of a .pdf file to a .png file with 16 million colors at 600 dpi. The nice thing is you don't have to specify the page size output since the .pdf file already has this information, you just set the horizontal and vertical resolution (DPI, or ppi). Code: gs -sDEVICE=png16m -sOutputFile=test1.png -r600x600 test2.pdf After that however I found an even simpler way -- direct importation into Gimp. I was unaware Gimp could directly import .pdf files. This dimmediately solves the problem of needing to transfer high resolution drawings from Draw to a bitmap editor. Files can also be saved in any bitmap format from Gimp. Apparently a lot of other people are unaware that this is possible, since so many have tried workarounds. While this may make the ghostscript code above irrelevant, perhaps it may be useful for someone needing to do batch exports from Draw (or other) .pdfs. Hope this helps others. I would still naturally hope OODraw will upgrade it's bitmap exports, but this does now make it less pressing an issue, since there is a ready way to get hi-res drawings out.
Unfortunately, there are many misunderstandings regarding image resolution and DPI/LPI/PPI/(SPI). I therefore need to clarify some aspects. Also, many things do NOT look like they are (or, are NOT perceived as they are). Hopefully, some aspects will be clarified after reading this post. I will attach later on some screenshots from Adobe Illustrator to emphasise these points. 1.) DPI and LPI are printer measures: - DPI is the maximum number of dots a printer can access per inch -- DPI points are just printer ink present or absent -- a DPI dot can NOT show various nuances of a colour - LPI is lines per inch, lines made up of the smaller dots from DPI to create the various colours we see in an image -- an LPI dot can be made of many dozen DPI dots -- more DPI dots will more accurately recreate the original colour, so smaller LPI is not necessarily worse [LPI is the printer equivalent of the monitor pixel, of what we see.] 2.) Images are stored as pixels (lets ignore for the beginning vector graphics for the sake of clarity). However, pixels have NO dimension. - a 100 x 50 px image could be 10 x 5 inch, or 2 x 1 inch, or 50 x 25 inch 3.) There is NO relationship between pixels and DPI/LPI - pixels just tell us what information is stored (actual information in digital pictures) - therefore, changing the DPI won't modify the quality of a non-vector image, just the size of the printed output [we will see a benefit only for vector images - arguably, this is why this feature will impact Draw export as we work with vector images] CRUCIAL VARIABLE ================ LPI is the important measure, but it is little known by ordinary people. Most importantly, it is usually not provided with the printer documentation (see later). I therefore would have preferred initially to specify the DPI for the target output. It is known for a specific printer and people have heard of it (though many will misunderstand it). There are however some problems with DPI that made me revise my initial opinion: - newer printers have stated DPIs of 1,200 and higher dots per inch values - this higher DPIs don't scale linearly with LPI values - actually, a 2,400 DPI office/home user printer will fare only slightly better than a 600 DPI ordinary printer (2,400 DPI is in this respect completely misleading) Even professional printing requires at most a picture scaled for 200-300 LPI output. A.) PRAGMTIC APPROACH ===================== This is why I favour a pragmatic approach: - Let user choose between 3 predefined OPTIONS: -- screen: 72 PPI (or LPI; for screens, PPI is the more accurate term) -- medium: 150 LPI (pixel equivalent, or PPI) -- high: 300 LPI (pixel equivalent, or PPI) This is exactly what Adobe Illustrator Dialog "Document Raster Effects Settings" offers, too (see the first screenshot). B.) ADVANCED APPROACH ===================== The advanced approach will display both the LPI and DPI options for that particular printer. This is also available in Adobe Illustrator, see the 2nd screenshot. Unfortunately, the translation of DPI to LPI: - isn't straightforward, - is printer dependent (and also on page type) - I do not know reliable informations for such translations - Adobe offers so called PPD-files containing such information for a particular printer (but I do not know if such information is opensource) EXAMPLE OF PPD FILE-INFO: Modified PPD (postscript printer description) file for Agfa Avantra 25 year 2002, postscript level 2). Defined paper formats: * A0 to A10, * B0 to B10, * USLetter and USLegal, * user defined formats. Defined resolutions: * 600 dpi – 40 lpi, * 846 dpi – 85 lpi, * 900 dpi – 60 lpi, * 1016 dpi – 70 lpi, 80 lpi, * 1200 dpi – 65 lpi, 75 lpi, 85 lpi, 100 lpi, 110 lpi, 120 lpi, 133 lpi, 140 lpi, 150 lpi, * 1270 dpi – 65 lpi, 75 lpi, 80 lpi, 90 lpi, 100 lpi, * 1693 dpi – 80 lpi, 100 lpi, 133 lpi, * 1800 dpi – 112 lpi, 133 lpi, 150 lpi, * 2032 dpi – 85 lpi, 110 lpi, 133 lpi, * 2400 dpi – 85 lpi, 100 lpi, 110 lpi, 120 lpi, 133 lpi, 140 lpi, 150 lpi, 160 lpi, 175 lpi, 200 lpi, * 2540 dpi – 100 lpi, 110 lpi, 120 lpi, 133 lpi, 138 lpi, 150 lpi, 175 lpi, * 3200 dpi – 200 lpi, * 3386 dpi – 100 lpi, 120 lpi, 133 lpi, 175 lpi, 200 lpi, * 3600 dpi – 133 lpi, 140 lpi, 150 lpi, 175 lpi, 200 lpi, 225 lpi, 250 lpi, 300 lpi, * 4800 dpi – 300 lpi. From the previous example, see that even a 4,800 DPI printer outputs actually only 300 LPI. So, e.g. for a 10 x 5 inch image, the resolution suffices to be 3,000 x 1,500 pixels. Hope this removes some of the misunderstanding and also will foster the implementation of a simple but powerful approach to this issue. This implementation should also guide unsuspecting users into following the best practice available. The pragmatic approach would just do this. [See: http://www.schulz-kirchner.de/dwl/Adist4.ppd.txt for another PPD-file.]
Created attachment 52118 [details] Adobe Illustrator Dialog: Document Raster Effect Settings used to set the LPI/DPI when exporting raster data
Created attachment 52119 [details] Adobe Illustrator Print/Export Dialog
Created attachment 52124 [details] Basic Mockup for this feature (not yet thought out in full detail - just a draft)
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.
@discoleo "1.) DPI and LPI are printer measures" I strongly disagree with this statement in the context of a bitmap export. You have a print-oriented view, but this bug is not about printing it's about exporting to a file so the target are other computer programs not just printers. For a computer program "DPI" (as used both by proprietary programs such as Visio and FLOSS programs such as the Gimp) is the ratio between the image dimension in pixels (pixel being the basic bitmap unit) and the image dimension in inches (physical unit, used to measure other parts of the document). Without LPI does not exist in this context. It may be relevant for printers but not at the computer stage. So when you resize a bitmap or export to a bitmap file, you need to display three sets of values 1. the image size in pixels 2. the image size in physical units (inches or millimeters depending on the locale) 3. their ratio in DPI Changing 1. changes 2., changing 2. changes 1., changing 3. changes 2. The user can follow several strategies to select the DPI value: 1. size the image "as on-screen", using the DPI ratio of his current screen (Current OO.o strategy. Unsuitable for many usages but valid in some contexts 2. size the image for a generic streen target, using common screen DPI values such as 75, 96 or 100 dpi 2. size the image with a print target in mind, using common print DPI values (150, 300, 600) 3. just cram the maximum number of pixels into a specific physical size, avoid any dithering in the current program to preserve pixel info, rework the bitmap in something else. This will result in very strange one-of-a-kind DPI values but is a valid use-case newertheless
@discoleo "1.) DPI and LPI are printer measures" I strongly disagree with this statement in the context of a bitmap export. You have a print-oriented view, but this bug is not about printing it's about exporting to a file so the target are other computer programs not just printers. For a computer program "DPI" (as used both by proprietary programs such as Visio and FLOSS programs such as the Gimp) is the ratio between the image dimension in pixels (pixel being the basic bitmap unit) and the image dimension in inches (physical unit, used to measure other parts of the document). If you don't associate the correct DPI info to an image file conversion to a pixel oriented space (vector export to bitmap) or to a physical unit oriented space (bitmap insertion in Office document, printing a bitmap file) will give unexpected results. LPI does not exist in this context. It may be relevant for printers but not at the computer bitmap export stage. So when you resize a bitmap or export to a bitmap file, you need to expose three sets of values 1. the image size in pixels 2. the image size in physical units (inches or millimeters depending on the locale) 3. their ratio in DPI Changing 1. changes 2., changing 2. changes 1., changing 3. changes 2. The user can follow several strategies to select the DPI value: 1a. size the image "as on-screen", using the DPI ratio of his current screen (Current OO.o strategy. Unsuitable for many usages but valid in some contexts 1b. size the image for a generic streen target, using common screen DPI values such as 75, 96 or 100 dpi 2. size the image with a print target in mind, using common print DPI values (150, 300, 600). (2400 in this context is totally insane, you don't map a pixel to a print point, what printers do is take the bitmap file DPI value to compute it's expected print size, and then interpolate pixels in print points to respect this size) 3. just cram the maximum number of pixels into a specific physical size, avoid any interpolation in the current program to preserve pixel info, rework the bitmap in somewhere else. This will result in very strange one-of-a-kind DPI values but is a valid use-case newertheless Therefore a good bitmap export dialog (not a print dialog disguised into bitmap export) would look like this Export ( ) Selected (o) Visible area ( ) Whole page¹ ¹ Usually one does not want to export huge bands of nothing around a drawing Image size (o) Custom Width [ ] Height [ ] [link¹] <Unit dropdown²> ¹ linking locks the ratio means changing width also changes height to preserve their ratio ² with pixel as default, physical units as alternatives. Changing the unit converts the Width/Height values to the new unit ( ) Scale to standard paper size Size <A0,A4... dropdown> Margins¹ Top [ ] Bottom [ ] Left [ ] Right [ ] ² ¹ When you target a paper format, you need margins ² In locale-dependant physical units, since standard formats use physical units Resolution ( ) Custom X Resolution [ ] Y Resolution [ ]¹ [link²] <unit³> ¹ Yes it is valid to have different values for X and Y in this context ² Linking forces the same value on the other dimension when one is modified ³ Unit being pixel/inches by default (what is commonly called dpi) with pixel/mm… as alternatives. Changing the unit changes the value of X/Y (converts them to the new unit) ( ) Use screen/web-oriented resolution <dpi value dropdown¹> ¹ Default value: current screen settings Alternates: usual screen DPI values (72dpi, 75dpi, 96dpi, 100dpi, 125dpi) If "scale to standard size" was not selected before changing a value there does not change the image size in pixels but the image size in physical units. ( ) Use print-oriented resolution¹ Resolution <dpi value dropdown²> ¹ Auto-selected if "Scale to standard paper size" is selected before ² Default value: last selected one, 150dpi initially otherwise Alternates: usual print DPI values (300, 600, etc) If "scale to standard size" was not selected before changing a value there does not change the image size in pixels but the image size in physical units. And then you have the usual transparency/interpolation algorithm options this bug is not concerned with
> ... "DPI" [...] is the ratio between the image dimension in pixels [...] > and the image dimension in inches This is mostly nonsense. DPI was and is *dots per inch* defining the characteristics of an output device (more correctly DPI is used for printers, PPI for monitors and SPI for scanners). DPI is the measure of how many dots of ink or toner a printer can place within an inch (or centimeter), and not pixels per inch. [A printer dot is not a pixel, see the explanatory section at the end.] It never defines a picture characteristic. [If you wish, you can view it somewhat the other way round: the image dimension in inches when printed is the ratio between the image resolution in pixels and the LPI for that printer, where LPI is usually much smaller than DPI, and only for pure black-and-white lineart, LPI = DPI. Unfortunately, LPI does not accurately reflect inkjets, because these machines use a different error diffusion dithering technology.] DPI is a *hardware* characteristic of the output device (more precisely of the printers halftone grid for laserjet printers). It is a physical characteristic of the printer. What you are referring to is probably more closely related to PPI: pixels per inch. IF people are more comfortable with PPI, than lets use PPI instea of DPI. [The printing-industries term for resolution is LPI, lines per inch. I opt for PPI however, because it is likely that LPI will increase the misunderstanding. Even Adobe chooses PPI in its products. Though, please remember that PPD printer descriptor files contain the LPI values.] HOWEVER: - PPI is very different from DPI - PPI requirements are much smaller than the hardware DPI of the output device [they are very distinct measures, so it makes little sense to compare them, BUT if you want to print in colour on a 600 DPI printer, it will suffice to have a 60-100 PPI image] Even IF you consider editing the image in an external application prior to printing, it is enough to add only a 50% to 100% overhead over the capabilities of the output device. Therefore, IF you plan to print on an 100 LPI printer, then 150-200 PPI will suffice most of the time, and 300 PPI will almost certain be overkill. [Please ignore anything that sounds bigger than 400 because any search for such a printer or output device will fail.] Just as a real example: high quality art books and glossy magazines are usually printed at 200 LPI. IF for reasons of prepress editing you add some buffer pixels (50%), you will end with 200 + 100 = 300 PPI images. Therefore, eveything that is above 300 PPI (LPI) is just a colossal waste of time and resources for over 99.99% of users. [Higher SPIs are needed for the scanner, especially if the original image gets resized, but this is a different story.] ===================== The next section tries to explain the vast difference between DPI and LPI. RATIONALE: ========== Now, unfortunately, printers can print only a dot of a single color, be it black (BW printers), or either one of black, cyan, magenta or yellow dots. They can not print any other colour (including gray colors). So, you can not print directly any of the 16.8 million colours in the RGB colourspace, but just some 4 colours (on some printers 6 colours). To actually achieve any of the many other colours, the printers will print a grid of dots consisting of these fundamental colors. Therefore, for every pixel in the original image, the printer will need to print up to 100 dots (and even more) to get a similar colour to the original colour. > For example, some grid sizes for a 600 dpi printer are: > 1x1 shows 2 shades (black or white, 600 dpi Line art) ** > ** 1x1 is not halftones, it is simply called "line art" mode. > 6x6 shows 37 shades of gray, reducing image resolution to 600/6 = 100 lpi > 7x7 shows 50 shades of gray, reducing image resolution to 600/7 = 85 lpi > 8x8 shows 65 shades of gray, reducing image resolution to 600/8 = 75 lpi > 10x10 shows 101 shades of gray, reducing image resolution to 600/10 = 60 lpi [This applies also after editing a low-colour image, because most editing effects will introduce new colours - so you can't print in lineart anymore.] Also, newer printers advertising resolutions of 1,200 DPI and higher, while partially correct, are highly misleading. They are still bound to 300 (360) LPI, therefore diverting the usefulness of DPI values. For further details, see also: http://www.scantips.com/basics03.html http://desktoppub.about.com/cs/intermediate/a/measure_lpi.htm http://desktoppub.about.com/cs/intermediate/a/measure_dpi.htm http://www.scantips.com/basics3b.html [Note: imagesetters mentioned in the articles are very different machines!] This is why I strongly advocate the use of pragmatic values: - Let user choose between 3 predefined OPTIONS: -- screen: 72 PPI (or LPI; for screens, PPI is the more accurate term) -- medium: 150 LPI (pixel equivalent, or PPI) -- high: 300 LPI (pixel equivalent, or PPI)
>> ... "DPI" [...] is the ratio between the image dimension in pixels [...] >> and the image dimension in inches > This is mostly nonsense. DPI was and is *dots per inch* defining the > characteristics of an output device Your forget that for a computer program a screen is an output device and the dots of this output device are pixels. For a computer screen ppi = dpi Microsoft (Windows, Office) X.org (X Window) GNOME (The Gimp) Mozilla Foundation (Firefox) all use dpi for what you call ppi. In the context of a bitmap export (what this issue is about) dpi as printer resolution makes no sense. Bitmap export is about dpi as ppi (if you prefer the term). Bitmap image formats label dpi what you call ppi. I'm 99% sure the original reporter would be very surprised to see you misinterpret his dpi request as "dpi as printer resolution". I personally prefer the programs that display it as a pixel/inch value instead of using user confusing dpi/ppi abbreviations but I've seen enough of them to recognize what dpi in bitmap export context means.
Users unfortunately do not know much of preprint and printing. And if they know something, they most likely misunderstand it. Therefore, while it is sometimes useful to allow users finely control all parameters, I suggest a more pragmatic approach to let users (force them ;-) ) use the desirable parameters. This will ultimately enhance their productivity and create higher quality products (in the end making the end users more happy). 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 After deciding this, one can establish the target LPI (or PPI): 72 PPI vs 75-150-200 LPI (for pure BW lineart, one could indeed choose 600 LPI). Then I decide the dimension of the work (in cm, or in inch, or any valid measure). Having both PPI and dimensions, will automatically result in the pixels needed in the raster image. I wouldn't go the other way round: deciding on PPI and/or image size based on pixels. Because Draw is a vector-graphics processing program, pixels don't make much sense either. So, while it is useful to display the dimension of the resulting raster image in MB, and sometimes also the size in pixels, I won't bother much in putting great emphasis in finely controlling these values. The user should be educated in the proper way of creating high quality work. [Pixels are really useful only when displaying on screen, so this is probably another useful option to choose from at the beginning: onscreen vs printed work. When onscreen is selected, then instead of size or PPI use resolution in pixels.]
I'm afraid you display a distinct lack of understanding of what an Office suite is used for. Sure an office suite user print documents. But that's far from the only or even principal use. Most office documents will never see preprint or even be printed at all (in the impress case). So over-specializing the bitmap export for print-oriented people like you is a bad idea. > I suggest a more pragmatic approach to let users (force them ;-) ) > use the desirable parameters. That's not a pragmatic approach that's making impossible the use-cases you may not care about but other OO.o do need. > 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 is explicit in my proposal > After deciding this, one can establish the target LPI (or PPI): 72 PPI vs > 75-150-200 LPI (for pure BW lineart, one could indeed choose 600 LPI). This is also taken care of in my proposal > Then I decide the dimension of the work (in cm, or in inch, or any valid > measure). This is also possible in my proposal, except it considers pixels a valid dimension unit, because that's the unit most bitmap image users care about (or they wouldn't be using a bitmap format) > Having both PPI and dimensions, will automatically result in the pixels needed > in the raster image. This will work in my proposal > I wouldn't go the other way round: deciding on PPI and/or > image size based on pixels. You wouldn't but others would wich is why it needs to work too > Because Draw is a vector-graphics processing program, pixels don't make much > sense either. When you export to bitmap, pixels are everything. If you don't care about them you don't need to do a bitmap export.
> I'm afraid you display a distinct lack of understanding of what > an Office suite is used for. Sure an office suite user print documents. > But that's far from the only or even principal use. > Most office documents will never see preprint or even be printed at all > (in the impress case). So over-specializing the bitmap export for > print-oriented people like you is a bad idea. I have created lots of presentations myself and seen well over thousand during my life (though most in a competitor's program). ;-) A.) IF you don't print the document, why do you need PPI (or LPI or DPI)? It amazes me how users make simple things look complicated. IF the only thing the user does is to view the image onscreen, then pixels is everything he ever wanted (and color depth - much neglected, but even more important than resolution). This is the reason why I wrote (in brackets, its true) that the first step is to decide if the work is for print or onscreen viewing. Becuase for onscreen viewing we don't need dimension in inches (or mm, or something else) and we don't need PPIs either. So lets make it simple: give only resolution in pixels. On the other hand, IF the user decides that the work will be printed, than 2 completely different parameters become relevant: dimension in length-units (mm or inches, ...) and the targeted output resolution (LPI). This becomes a different story. B.) "DPI" for monitors > You forget that for a computer program a screen is an output device > and the dots of this output device are pixels. > > For a computer screen ppi = dpi While dpi is sometimes misused for monitors, you can't set a monitor "DPI" for your image, because for every monitor and monitor resolution, this is a different value. So, how do you assign a range of values to something. Indeed, what a complex question. I can view an image in 1024*768 and using your definition will get a specific value for "DPI", then change my graphics card resolution to 1200*1024, and voila, for the same image and monitor I get a different "DPI". ;-) [Just to confuse matters further, there are 0.25 mm dots pitch monitors, but this varies between 0.24 mm in very good monitors to 0.27 mm in poorer ones. Additionally, every user uses different monitor settings, and the "PPI" will vary greatly from 800*600 to 1600*1200 resolutions. So, my recommendation: just ignore the PPI whenever the work is intended solely for onscreen viewing.] C.) Just a short comment on color-depth: this much neglected feature is more important than resolution itself. This is why an image displayed on a 72 PPI monitor looks so much better than even if printed on a 1.200 DPI printer. In the RGB colorspace are some 16.8 million colours. Arguably, even a good monitor is not able to display all these colours (but neither the human eye can discern them all), but a printer's CMYK colorspace is greatly diminished in comparison even with a monitor. This issue becomes also important when editing images using various software. The Gimp was mentioned previously, unfortunately, it can handle only 24 bit-colors. This is relevant when performing image-processing in hingh end settings, where 8bit/channel does not suffice: 12 and 16-bit per channel is much better, because intermediate calculations might use values that exceed the possibilities of an 8 bit number. This is especially tragic with Gimp, because some years back, someone (or a corporation ? - forgot it) provided some patches to extend Gimps capabilities (I think to 16 bits per channel), but in one of the greatest shortsightednesses, the developers refused to implement them. So, when exporting a rasterised graphic, at least as important as the spatial resolution is also the colour resolution. When I teach image processing, I do some little experiments with students: take an image and reduce the spatial resolution vs reduce the colour resolution. You may see yourself what dramatic effects colour resolution has.
> A.) IF you don't print the document, why do you need PPI (or LPI or DPI)? Again DPI/PPI is used to scale between pixel-space and physical unit space. Correct DPI is what will make your bitmap file to have the right size when inserted in another Office document. Also it's customary to have strict DPI value rules when creating a set of materials. These rules can be print-oriented, web oriented or something else entirely and letting the user choose the exact DPI he needs is a requirement of any serious bitmap-producing graphic application. > While dpi is sometimes misused for monitors, you can't set a monitor "DPI" for > your image, because for every monitor and monitor resolution, this is a > different value. You're lacking imagination, labs of screens with the same characteristics are not that uncommon. Also it's not unheard-of to prepare material for the system currently been used. In this case the exact dpi value is well known. > C.) Just a short comment on color-depth: this much neglected feature is more > important than resolution itself. Feel free to open a separate issue. In crappy hardware corp-land, your colours will suck whatever color-depth is chosen. The Gimp will be fixed way before this situation changes, since calibrating screens/printers is on no one's radar yet (and in fact the hardware is getting worse in this respect).
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.
> However, I would > suggest that the "screen" vs "print" resolution could be collapsed into just > one dropdown to make the interface simpler. It offends my engineering sensitivities too since it's really the same thing in both cases however discoleo is right in that some users have no clue and need tight guidance. For that reason other software (visio 2003) make this distinction in their bitmap export UI.
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 B&W 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.
> In the context of a bitmap export (what this issue is about) > dpi as printer resolution makes no sense. [and] > Again DPI/PPI is used to scale between pixel-space and physical unit space. > Correct DPI is what will make your bitmap file to have the right size when > inserted in another Office document. > ... I don't get it. To quote the woodcutter in Rashomon: "I just don't understand." IF this whole issue is not about monitor resolutions (which, by the OOo default value of 96 PPI is way above most users monitors), and not about professional printing (max 300 PPI) then what it is about? I proposed a simple and comprehensive and correct solution. Now, I would like to add some further comments on this, but first I will start with a motto: Langsam's ornithological axiom: It's hard to soar with the Eagles when you work with Turkeys. Before we discuss anything further, I invite you to watch a tutorial for Adobe Illustrator CS3: http://www.adobe.com//designcenter/video_workshop/index.html?id=vid0284 Now, if OOo Draw wants to become competitive, it should compare itself with the de facto standards. For vector graphics, these are Adobe Illustrator and CorelDraw. [I appologise to Corel users because I stick to Adobe products, but - although I did have a valid, licensed Corel version in 1995, it never caught me up.] The complete discussion is posted on the UX-mailing list, please see: http://ux.openoffice.org/servlets/ReadMsg?list=discuss&msgNo=1452
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.
Created attachment 52192 [details] Corel Draw Convert to Bitmap Dialog
I've been watching this issue for a long time now and I find it almost laughable the way it's being debated so heatedly now. But I just had to put in my two bits. My take on the matter is why limit the functionality? If even some people want to be able to set the DPI, put in a place to do it, and why limit it? Obviously there has to be some limit, but why not make it absurdly high? (discoleo mentioned Corel Draw, it allows the user to select up to 10,000 DPI, as well as your choice of measure measurements and why not? See last Attachment.) Chances are there won't be anyone wanting that high of a resolution, but that means that hopefully no one will wish it had more. If there is a need to educate people on what settings should "normally" be used, add a nice help page to go along with it indicating typical setting for various cases. I personally have worked with people that have to send graphics to be printed as well as use them on the web. DPI is a big deal. (By the way there are Ink Jet Printers out there that boast a 2400 DPI resolution, perhaps this is not realistic, I don't pretend to know, but I can assure you there are users out there that will want there image to have that high of a resolution as well) So all I'm saying is leave options. I'm not a serious user myself, and I will typically only play with export setting a little, but I hate being restricted to the "normal" settings, it makes me feel like I'm using a restricted or cheap program. Open Office is used by a lot of people for a lot of things, and right now Draw is one of the most disappointing parts of it in my opinion. And frankly this issue is one of the bigger problems. So lets get it fixed and please don't limit it to "normal" settings, there is no reason for it. People like to have control. I also REALLY like the idea of being able to export "selected" I use it all the time in Corel Draw. It's a very handy feature that saves a lot of time.
<smerkley> I also REALLY like the idea of being able to export "selected" I use it all the time in Corel Draw. It's a very handy feature that saves a lot of time. Just select something, choose file/export and you have the selection checkmark enable. all there
> My laptop has 110 dpi. ME: LAUGHING ALL OVER I say it again and again (see my previous posts): > Additionally, every user uses different monitor settings, > and the "PPI" will vary greatly from 800*600 to 1600*1200 resolutions. > So, my recommendation: just ignore the PPI whenever the work is intended > solely for onscreen viewing. I cannot overemphasise the previous advice. To better illustrate this point, see the next table. I see my monitor easily beats your "110 DPI LCD"! ;-) MONITORS DPI *APPARENT* resolution of different size CRT monitor screens Screen Size | 14 inch 15 inch 17 inch 19 inch 21 inch [Pixels] monitor monitor monitor monitor monitor 640 x 480 | 66 dpi 60 dpi 51 dpi 44 dpi 40 dpi 800 x 600 | 82 dpi 75 dpi 64 dpi 56 dpi 50 dpi 1024 x 768 | 106 dpi 97 dpi 82 dpi 71 dpi 64 dpi 1280 x 1024 | 132 dpi 121 dpi 102 dpi 89 dpi 80 dpi 1600 x 1200 | 165 dpi 151 dpi 128 dpi 111 dpi 101 dpi [from http://www.scantips.com/no72dpi.html] The explanation is just wonderful, and I am too lazy to explain it myself, so please read this excerpt: > The numbers 72 and 96 dpi do sort of exist (in their imaginary way) > in computer operating systems. This existence does seriously confuse > people who imagine these numbers might be about showing images, but > these numbers never affect any image in any way. These numbers are > only used to compute Text Size on the screen. The reason is because > text font size in Points is dimensioned in inches (designed for paper), > but screens are only dimensioned in pixels. The definition of a Point is > 1/72 inch - there are 72 points per real inch on paper. A 12 Point font > is 12/72 inch height printed on paper (inches exist on paper, and paper > is dimensioned in inches, and fonts are dimensioned in inches). ... > But not to worry, the operating system simply dreams up and uses some > fake 72 and 96 dpi numbers to compute text size on the screen. [see http://www.scantips.com/no72dpi.html]
> The explanation is just wonderful, and I am too lazy to explain it myself, so > please read this excerpt: It's also totally clueless. There is a concept of DPI in video and computer programs do care (as the long list of user problem reports every time the computer gets its internal DPI wrong shows).
> By the way there are Ink Jet Printers out there that > boast a 2400 DPI resolution Only that the printer can print only a dot of a single color: - either cyan, magenta, yellow or black - to print a different color (including shades of gray), it will use many of these dots to emulate a single picture "pixel" - for 101 shades of gray, it needs 100 dots (a grid of 10 x 10 dots) => real resolution: 2400 / 10 = 240 pixels per inch with 101 shades of gray [this explanation is slightly inaccurate, because Inkjets use a different error diffusion dithering technology than Laserjets] Bear in mind, that even this Agfa (which is an industry standard Imagesetter, see http://www.c-doc.com/agfa_avantra_series.htm) does print only 300 pixels per inch (so called LPI). [Its max LPI is between 400-500, but it usually prints at 300 LPI.] So what chances do you believe exist, that an office printer matches the resolution of the Imagestter? I would clearly answer NIL!
For anyone that has tried to open my "Corel Draw Export Dialog.jpg" attachment I don't know why it doesn't work properly, (at least it didn't for me), but it did open just fine when I downloaded the "link target". So the file is intact, but there must be something irregular about it making it so it isn't displayed on the website. If anyone knows how to fix it, I certainly wouldn't mind it being done. Oh, and thanks to cl for pointing out that Draw already has the export "selected" feature. Tells you how little I've bothered to use it.
I can see your point, however I did a little looking and Canon has this printer http://www.usa.canon.com/consumer/controller?act=ModelInfoAct&fcategoryid=182&modelid=12892#ModelTechSpecsAct that retails for $500. It was a maximum DPI of 4800x2400. Now I don't want to go so much into the nitty-gritty details, I think it's beside the point. However I do want to point out that printers are getting better and as they do the user will want higher resolutions. Why not just set it up so they can pick whatever they want. (Then write that help page I mentioned before to teach people all this stuff about how your resolution doesn't have to be so high.) I have to admit that I did have some misconceptions, and I'm sure now that discoleo knows more about this stuff than I do. But at the same time I'm a believer in over engineering. That way 5 years down the road hopefully it will still be adequate.
Please all be aware that the discussion about the maximum dpi/ppi/lpi is starting to just spam this issue. If this continues I'm going to close this issue and reopen another one. If you like to just discuss things please use the mailing list. I will implement the valid range from a minimum of 1 dpi to a maximum of 65535 dpi. And I have choosen this values for no particular reasons.
Just tested the OOo-Export extension that enables the users to set the PPI-value for the exported bitmap. The extension can be downloaded from: http://lippka.com/EnhancedGraphicExportDialogs.oxt Be aware, this is a very first prototype and many features are unavailable and others may be buggy. Read the full details here: http://ux.openoffice.org/servlets/ReadMsg?list=discuss&msgNo=1559 Now, as said this is an initial testing version, but there are some potential glitches/problems that I spotted while testing the extension. 1.) the color-export mode does not get set (it is actually specified in the release-mail) Unfortunately, I am now stuck at exporting gray-scale images only. [I previously tested issue 87410, http://www.openoffice.org/issues/show_bug.cgi?id=87410, and after installing the extension, there is no possibility to set a different color mode - it does not have any effect.] 2.) more RAM needed than actually predicted I exported a 9999 x 9999 pixel jpg-image. (see the attachemnet: BE AWARE: IF YOU DO NOT HAVE ENOUGH MEMORY, IT MIGHT CRASH YOUR COMPUTER!!!) My memory-load jumped from: 429,688 MB to 1,209,980 MB this is an increase of almost 800 MB RAM, much more than the 286 MB anticipated for this image NOTA BENE: when opening the image in IrfanView, the memory-load jumped to: 1,581,180 MB, that is an increase of over 1 GB RAM for decoding!!! 3.) Trying to resave the image a second time does NOT work. Strangely, although I do have enough RAM to export this big image once, and the memory-load does get back to ~405 MB after export, and I do have enough RAM for even bigger images, I get reproducible always: - the 2nd export does NOT work - error message: "Graphics filter not found." when I click OK, a 2nd Error-dialog appears ["... Write Error. ..."] After restarting the computer, I am able to export again only once, then the export fails the second time. 4.) exported image has 9998 x 9998 pixels Instead of 999_9_ pixels, I reproducible get 999_8_ pixels. Rounding-Error? I though pixels are used directly for export. Well, I think I covered mostly the small glitches. The dialog looks otherwise quite fine. A last note: THE ATTACHED IMAGE IS REALLY HUGE AND MOST COMPUTERS WILL FAIL TO OPEN IT AND MAY EVEN CRASH!!!! EVEN THOUGH THE FILE SIZE ON DISK IS VERY SMALL (ONLY KB !!!), THE SIZE IN RAM IS ENORMOUS!!! (NEED 1 GB RAM TO OPEN IN IRFANVIEW) PLEASE SAVE ANY UNSAVED WORK/DOCUMENTS BEFORE ATTEMPTING TO OPEN THAT FILE.
Created attachment 52515 [details] PICTURE IS HUUUUUGE. MIGHT CRASH YOUR COMPUTER. DO !!!NOT!!! OPEN IF UNSURE.
I uploaded a new version of my extension to http://lippka.com/EnhancedGraphicExportDialogs.oxt As always, in OpenOffice.org go to "Tools/Extension Manager..." and click on "Add". Select the downloaded extension and close the dialog. If you want to de install this extension you can also do this later with the extension manager. If you installed my previous version, I recommend that you remove it first. I hope the next version will have online update working. Again this extension replaces This extensions replaces the export dialogs for the filters png, jpeg and gif in impress and draw. All filter settings in the dialog should now be applied to the export, including the color mode for jpeg. The chosen dpi is now also remembered. Still no slider since this control is not yet available for extensions, but I resized the scroll bar and changed the spin field to an edit. I think this is not so bad already. Reworked error handling when inputing invalid values for width, height and dpi. Estimated file size still not working. I hoped I could figure out some factors to calculate it from the image size in memory but it depends to much on the contents of the exported image. So I have to create a temporary export (of a probably smaller version to speed it up) to figure out the estimated file size. The next version should have localized strings. I'm able to do this for English and German. If someone likes to help me translate to another language please send me an email.
Obviously transparency needs to be added as soon as the actual filters allow for this. Does anyone know what time this could be expected? In particular 32bit PNG? Would it also be possible to incorporate this (http://qa.openoffice.org/issues/show_bug.cgi?id=18674) into the dialog. Much like Corel Draw / Photo Shop has a check-box for applying colour correction into the exported image and a combo box for selecting the output profile. E.g.: (x) Use colour matching [sRGB Profile ^] Maybe even go further with TIFF / JPG by adding a secondary option, i.e.: ( ) Embed colour profile As to the DPI, LPI, SPI, PPI scenario. That's probably just semantics for this particular problem. Usually the user simply wants to export at a "resolution" high enough not to start pixelating the image when imported into another prog. So (whatever you call it DPI, PPI, etc.) give some defaults (e.g. 96, 100, 150, 200, 300, etc.) but allow for custom as well. Never force your opinion onto the user - give her the power to decide but also make it easier (therefore defaults with a custom option for those techy types). The current dialog only has the custom option - could this be changed to a combo-box with the defaults as stated previously but allow the user to enter a different value as per now?
*** Issue 96097 has been marked as a duplicate of this issue. ***
FYI, I uploaded my extension to the OpenOffice.org extension repository for better visibility. Check it out at http://extensions.services.openoffice.org/project/EnhancedGraphicExportDialogs Its the same version as linked here, I just fixed the strings for the JPG compression. Hopefully for 9.2 this will be part of the default install....
*** Issue 98436 has been marked as a duplicate of this issue. ***
Why an extension? This is a basic function that each vector drawing program (except OOo Draw at the moment) offers. Please include it directly into the OOo builds!
I suppose as soon as the extension works correctly it'll be incorporated. Many a new feature (not just in OOo) happened in this way. Take for example the Lightning add-on for Thunderbird ... it's now going to be incorporated into TB3. But you're correct, if OOo Draw wants to be a decent alternative to other vector packages, this is a must (not an option)!
Are we on track for 3.2 with this issue? WBR, KP.
Beside the export to PNG, JPG or GIF, as supported by version <a http://www.openoffice.org/issues/show_bug.cgi?id=4499#desc105>0.0.2-rc-1</a> of the very much appreciated plug-in from cl, the possibility to export to TIFF as well as to set the colour depth is also needed. See <a http://extensions.services.openoffice.org/project/EnhancedGraphicExportDialogs#comment-1433>http://extensions.services.openoffice.org/project/EnhancedGraphicExportDialogs#comment-1433</a>
had no time for this issue, retarget
cl->sj: thanks for taking over
This is a long task, and it is difficult to take care of each proposal. So I took the EnhancedDialogExtension from cl as basis to redesign a new dialog that is used for each filter now, so the export resolution can be set for each bitmap filter. This dialog is now also used for each vector filter and it is possible to set the logical size for each vector export. Having only one dialog for each filter is a good start for further improvements. Two examples of the new dialog are attached.
Created attachment 70053 [details] png export example
Created attachment 70055 [details] eps export example
sj->wg: this issue is ready to be verified in cws[impress186]
changed target, as wg told me it is too late for OOo3.3.
@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...
Verified in CWS.
@crxssi there is no longer a limit of 2000... pixels... I know that filter formats may have its own limit.. for sure, I will implement the max pixels resolution for each filter, so long you can enter each resolution, but if your entered resolution is bigger as the destination file format allows, then you will get something special... This is something the new export dialog doesn't care atm. Somebody needs to write a ne Issue giving the correct maximum pixel count for each filter... But I think the change we made is reasonable for most users... also for lo users..
Modifying the resolution in the dialog does not have any effect. See http://svn.apache.org/viewvc/incubator/ooo/trunk/main/svtools/source/filter/exportdialog.cxx?revision=1198302&view=markup#l1478 when the Resolution value is modified, the resolution is updated but the call to ExportDialog::updateControls() does not update the size. See http://svn.apache.org/viewvc/incubator/ooo/trunk/main/svtools/source/filter/exportdialog.cxx?revision=1198302&view=markup#l1300 maSize member is never updated reflecting the Resolution change.
(In reply to comment #120) > Modifying the resolution in the dialog does not have any effect. > See > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/svtools/source/filter/exportdialog.cxx?revision=1198302&view=markup#l1478 > when the Resolution value is modified, the resolution is updated but the call > to ExportDialog::updateControls() does not update the size. See > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/svtools/source/filter/exportdialog.cxx?revision=1198302&view=markup#l1300 > > maSize member is never updated reflecting the Resolution change. ignore comment. Back to fixed.
Visit US to get more Support https://www.ij-startcanon.co/ https://www.ijstartcanon.us/
amaziing https://www.httpijstartcanon.com/ https://canondrivermac.com/ https://canonij.co.uk/ https://samsungsupports.com/ https://brothersdriver.com/ https://www.brotherusadrivers.com/ https://canondriversupports.com/ https://brothersupports.com/ https://canonijprintersetup.com