Re: [JPP-Devel] Rendering problems affecting the quality of printing
Very interesting. I don't have a great trust of Autodesk either. (It's hard when they keep violating their customers with forced upgrades.) SS On 7/11/07, Larry Becker <[EMAIL PROTECTED]> wrote: > Hi Sunburned, > > I actually got on board with DWF back in 1995 when AutoDesk first > introduced the WHIP! web browser plug-in. I got the "free" SDK and > started developing an application based on it. Imagine my surprise > when I got a letter from AutoDesk saying that they were revoking the > licenses of all developers using their product. This pretty much > killed DWF for a decade. I see that it is making a comeback lately, > but it has still left a bad taste in my mouth. I have a hard time now > trusting any format that isn't truly free in the FSF sense. (Yes, DXF > isn't free either, but it isn't going away soon in CAD circles > either.) > > regards, > Larry > > > On 7/11/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > Larry wrote: "Our users typically produce maps for limited distribution in > > two > > different formats: DXF and PDF. It also may be printed on either a > > standard printer or a large size plotter in order to study it more > > closely or prepare for a meeting with a client. > > > > The advantage of the DXF distribution is that it can be opened in free > > CAD viewers which have exact measurement tools. The advantage of the > > PDF is that it is ready to print and everyone understands it." > > > > I have been exploring the use of DWF as a means for distributing CAD > > data as an alternative to PDF. Autodesk has made the DWF viewer and > > WXF writer available for free, and more importantly the DWF file > > format is available in a published spec. DWF allows for easy printing, > > measurment in the drawing with snaps, and markup/commmenting tools. > > > > Just a thought... > > > > The Sunburned Surveyor > > > > > > On 7/8/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > I would be interested in the perceptual limit. > > > > > > Our users typically produce maps for limited distribution in two > > > different formats: DXF and PDF. It also may be printed on either a > > > standard printer or a large size plotter in order to study it more > > > closely or prepare for a meeting with a client. > > > > > > The advantage of the DXF distribution is that it can be opened in free > > > CAD viewers which have exact measurement tools. The advantage of the > > > PDF is that it is ready to print and everyone understands it. > > > > > > The disadvantage of PDF is its limited usefulness for viewing on > > > screen. Zooming is limited and graphics tend to look "chuncky" and > > > imprecise. This is why I am trying to improve the printing quality to > > > PDF. The current output looks somewhat unprofessional. > > > > > > regards, > > > Larry > > > > > > On 7/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > > > > > The only thing that will make the SVG look different will > > > > > be a different styling. The right sizes of the graphical > > > > > attributes must have a physical measure. The output medium > > > > > has to have a physical measure. Than you can determine the > > > > > right scales. > > > > > > > > do you think that is possible? Since every printer has his own physical > > > > limits one probably needs to look for the printer settings... a bit > > > > tricky for different platforms? (ok.. at the end there is always a > > > > rastering, if one does not use pen-plotters..., so a solution may be to > > > > let the user define a DPI value in *JUMP). > > > > The other thing i can remark is that the human has perceptual limits to > > > > see something. I can post this minimum "mm" thresholds teached in > > > > cartography if somebody is interested. > > > > > > > > stefan > > > > > > > > > > > > > > What we need is a concept of a physical size based output device. > > > > > Renderers must be aware of this. This leads to a lot of refactoring. > > > > > As an alternative we can build a complete new rendering path, > > > > > which has to be consistent with the old one. WYSIWYG is another > > > > > word that comes to mind. What if someone add a new Layerable with > > > > > new Renderers? Should she or he implement the same logic twice? > > > > > > > > > > - Sascha > > > > > > > > > > Sunburned Surveyor schrieb: > > > > >> Larry, > > > > >> > > > > >> I know it is very easy to convert to SVG by using the JTS graphics > > > > >> painted on the LayerViewPanel and the Batik libs. > > > > >> > > > > >> I wonder if some of the problems could be eliminated by using the JTS > > > > >> Goemetries and Layer styling information to convert directly to SVG. > > > > >> > > > > >> Just a thought. > > > > >> > > > > >> The Sunburned Surveyor > > > > >> > > > > >> On 6/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > > >>> More surprises (for me). Someone stop me if this is already > > > > >>> documented. If you set the line width to zero, you get very faint > > > > >>> lines. The documentati
Re: [JPP-Devel] Rendering problems affecting the quality of printing
Hi Sunburned, I actually got on board with DWF back in 1995 when AutoDesk first introduced the WHIP! web browser plug-in. I got the "free" SDK and started developing an application based on it. Imagine my surprise when I got a letter from AutoDesk saying that they were revoking the licenses of all developers using their product. This pretty much killed DWF for a decade. I see that it is making a comeback lately, but it has still left a bad taste in my mouth. I have a hard time now trusting any format that isn't truly free in the FSF sense. (Yes, DXF isn't free either, but it isn't going away soon in CAD circles either.) regards, Larry On 7/11/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Larry wrote: "Our users typically produce maps for limited distribution in two > different formats: DXF and PDF. It also may be printed on either a > standard printer or a large size plotter in order to study it more > closely or prepare for a meeting with a client. > > The advantage of the DXF distribution is that it can be opened in free > CAD viewers which have exact measurement tools. The advantage of the > PDF is that it is ready to print and everyone understands it." > > I have been exploring the use of DWF as a means for distributing CAD > data as an alternative to PDF. Autodesk has made the DWF viewer and > WXF writer available for free, and more importantly the DWF file > format is available in a published spec. DWF allows for easy printing, > measurment in the drawing with snaps, and markup/commmenting tools. > > Just a thought... > > The Sunburned Surveyor > > > On 7/8/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > I would be interested in the perceptual limit. > > > > Our users typically produce maps for limited distribution in two > > different formats: DXF and PDF. It also may be printed on either a > > standard printer or a large size plotter in order to study it more > > closely or prepare for a meeting with a client. > > > > The advantage of the DXF distribution is that it can be opened in free > > CAD viewers which have exact measurement tools. The advantage of the > > PDF is that it is ready to print and everyone understands it. > > > > The disadvantage of PDF is its limited usefulness for viewing on > > screen. Zooming is limited and graphics tend to look "chuncky" and > > imprecise. This is why I am trying to improve the printing quality to > > PDF. The current output looks somewhat unprofessional. > > > > regards, > > Larry > > > > On 7/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > > > > The only thing that will make the SVG look different will > > > > be a different styling. The right sizes of the graphical > > > > attributes must have a physical measure. The output medium > > > > has to have a physical measure. Than you can determine the > > > > right scales. > > > > > > do you think that is possible? Since every printer has his own physical > > > limits one probably needs to look for the printer settings... a bit > > > tricky for different platforms? (ok.. at the end there is always a > > > rastering, if one does not use pen-plotters..., so a solution may be to > > > let the user define a DPI value in *JUMP). > > > The other thing i can remark is that the human has perceptual limits to > > > see something. I can post this minimum "mm" thresholds teached in > > > cartography if somebody is interested. > > > > > > stefan > > > > > > > > > > > What we need is a concept of a physical size based output device. > > > > Renderers must be aware of this. This leads to a lot of refactoring. > > > > As an alternative we can build a complete new rendering path, > > > > which has to be consistent with the old one. WYSIWYG is another > > > > word that comes to mind. What if someone add a new Layerable with > > > > new Renderers? Should she or he implement the same logic twice? > > > > > > > > - Sascha > > > > > > > > Sunburned Surveyor schrieb: > > > >> Larry, > > > >> > > > >> I know it is very easy to convert to SVG by using the JTS graphics > > > >> painted on the LayerViewPanel and the Batik libs. > > > >> > > > >> I wonder if some of the problems could be eliminated by using the JTS > > > >> Goemetries and Layer styling information to convert directly to SVG. > > > >> > > > >> Just a thought. > > > >> > > > >> The Sunburned Surveyor > > > >> > > > >> On 6/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > >>> More surprises (for me). Someone stop me if this is already > > > >>> documented. If you set the line width to zero, you get very faint > > > >>> lines. The documentation for BasicStroke says, "If width is set to > > > >>> 0.0f, the stroke is rendered as the thinnest possible line for the > > > >>> target device and the antialias hint setting." > > > >>> > > > >>> Apparently when you create a new layer, the line width defaults to 1. > > > >>> I never noticed that you could drag it left to 0, or if I did I must > > > >>> have assumed it was an error. > > > >>> > > >
Re: [JPP-Devel] Rendering problems affecting the quality of printing
Larry wrote: "Our users typically produce maps for limited distribution in two different formats: DXF and PDF. It also may be printed on either a standard printer or a large size plotter in order to study it more closely or prepare for a meeting with a client. The advantage of the DXF distribution is that it can be opened in free CAD viewers which have exact measurement tools. The advantage of the PDF is that it is ready to print and everyone understands it." I have been exploring the use of DWF as a means for distributing CAD data as an alternative to PDF. Autodesk has made the DWF viewer and WXF writer available for free, and more importantly the DWF file format is available in a published spec. DWF allows for easy printing, measurment in the drawing with snaps, and markup/commmenting tools. Just a thought... The Sunburned Surveyor On 7/8/07, Larry Becker <[EMAIL PROTECTED]> wrote: > I would be interested in the perceptual limit. > > Our users typically produce maps for limited distribution in two > different formats: DXF and PDF. It also may be printed on either a > standard printer or a large size plotter in order to study it more > closely or prepare for a meeting with a client. > > The advantage of the DXF distribution is that it can be opened in free > CAD viewers which have exact measurement tools. The advantage of the > PDF is that it is ready to print and everyone understands it. > > The disadvantage of PDF is its limited usefulness for viewing on > screen. Zooming is limited and graphics tend to look "chuncky" and > imprecise. This is why I am trying to improve the printing quality to > PDF. The current output looks somewhat unprofessional. > > regards, > Larry > > On 7/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > > > The only thing that will make the SVG look different will > > > be a different styling. The right sizes of the graphical > > > attributes must have a physical measure. The output medium > > > has to have a physical measure. Than you can determine the > > > right scales. > > > > do you think that is possible? Since every printer has his own physical > > limits one probably needs to look for the printer settings... a bit > > tricky for different platforms? (ok.. at the end there is always a > > rastering, if one does not use pen-plotters..., so a solution may be to > > let the user define a DPI value in *JUMP). > > The other thing i can remark is that the human has perceptual limits to > > see something. I can post this minimum "mm" thresholds teached in > > cartography if somebody is interested. > > > > stefan > > > > > > > > What we need is a concept of a physical size based output device. > > > Renderers must be aware of this. This leads to a lot of refactoring. > > > As an alternative we can build a complete new rendering path, > > > which has to be consistent with the old one. WYSIWYG is another > > > word that comes to mind. What if someone add a new Layerable with > > > new Renderers? Should she or he implement the same logic twice? > > > > > > - Sascha > > > > > > Sunburned Surveyor schrieb: > > >> Larry, > > >> > > >> I know it is very easy to convert to SVG by using the JTS graphics > > >> painted on the LayerViewPanel and the Batik libs. > > >> > > >> I wonder if some of the problems could be eliminated by using the JTS > > >> Goemetries and Layer styling information to convert directly to SVG. > > >> > > >> Just a thought. > > >> > > >> The Sunburned Surveyor > > >> > > >> On 6/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > >>> More surprises (for me). Someone stop me if this is already > > >>> documented. If you set the line width to zero, you get very faint > > >>> lines. The documentation for BasicStroke says, "If width is set to > > >>> 0.0f, the stroke is rendered as the thinnest possible line for the > > >>> target device and the antialias hint setting." > > >>> > > >>> Apparently when you create a new layer, the line width defaults to 1. > > >>> I never noticed that you could drag it left to 0, or if I did I must > > >>> have assumed it was an error. > > >>> > > >>> This could be very handy when you are printing and the lines are > > >>> showing up too wide on the print device, or just when you have a lot > > >>> of linestrings very close together. > > >>> > > >>> regards, > > >>> Larry > > >>> > > >>> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > Interesting... It turns out that when rendering antialiased lines, > > Java2D actually draws lines with fractional widths as shown in the > > attached JumpWindow screen capture. This would make it possible to > > modify the Change Style line width slider to support floating point > > values that represent very thin lines. > > > > Larry > > > > On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > To give a better idea of problem (1), I have attached two jpegs. They > > > were made by doing a screen capture within Inkscape whil
Re: [JPP-Devel] Rendering problems affecting the quality of printing
ok.. at my home computer i have only a german version (with images), i will look tomorrow at my work place for the english version and send the (pdf) pages with the thresholds off-list to you (for copyright issues). I also used a few of the recommended minimum values for map making in the mapgen toolbox plugin: http://jump-pilot.cvs.sourceforge.net/jump-pilot/MapGenToolboxPlugin/src/mapgen/agents/goals/BuildingGoals.java?view=markup if anybody else is interest please send me a personal email stefan Larry Becker schrieb: > I would be interested in the perceptual limit. > > Our users typically produce maps for limited distribution in two > different formats: DXF and PDF. It also may be printed on either a > standard printer or a large size plotter in order to study it more > closely or prepare for a meeting with a client. > > The advantage of the DXF distribution is that it can be opened in free > CAD viewers which have exact measurement tools. The advantage of the > PDF is that it is ready to print and everyone understands it. > > The disadvantage of PDF is its limited usefulness for viewing on > screen. Zooming is limited and graphics tend to look "chuncky" and > imprecise. This is why I am trying to improve the printing quality to > PDF. The current output looks somewhat unprofessional. > > regards, > Larry > > On 7/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: >>> The only thing that will make the SVG look different will >>> be a different styling. The right sizes of the graphical >>> attributes must have a physical measure. The output medium >>> has to have a physical measure. Than you can determine the >>> right scales. >> do you think that is possible? Since every printer has his own physical >> limits one probably needs to look for the printer settings... a bit >> tricky for different platforms? (ok.. at the end there is always a >> rastering, if one does not use pen-plotters..., so a solution may be to >> let the user define a DPI value in *JUMP). >> The other thing i can remark is that the human has perceptual limits to >> see something. I can post this minimum "mm" thresholds teached in >> cartography if somebody is interested. >> >> stefan >> >>> What we need is a concept of a physical size based output device. >>> Renderers must be aware of this. This leads to a lot of refactoring. >>> As an alternative we can build a complete new rendering path, >>> which has to be consistent with the old one. WYSIWYG is another >>> word that comes to mind. What if someone add a new Layerable with >>> new Renderers? Should she or he implement the same logic twice? >>> >>> - Sascha >>> >>> Sunburned Surveyor schrieb: Larry, I know it is very easy to convert to SVG by using the JTS graphics painted on the LayerViewPanel and the Batik libs. I wonder if some of the problems could be eliminated by using the JTS Goemetries and Layer styling information to convert directly to SVG. Just a thought. The Sunburned Surveyor On 6/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: > More surprises (for me). Someone stop me if this is already > documented. If you set the line width to zero, you get very faint > lines. The documentation for BasicStroke says, "If width is set to > 0.0f, the stroke is rendered as the thinnest possible line for the > target device and the antialias hint setting." > > Apparently when you create a new layer, the line width defaults to 1. > I never noticed that you could drag it left to 0, or if I did I must > have assumed it was an error. > > This could be very handy when you are printing and the lines are > showing up too wide on the print device, or just when you have a lot > of linestrings very close together. > > regards, > Larry > > On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: >> Interesting... It turns out that when rendering antialiased lines, >> Java2D actually draws lines with fractional widths as shown in the >> attached JumpWindow screen capture. This would make it possible to >> modify the Change Style line width slider to support floating point >> values that represent very thin lines. >> >> Larry >> >> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: >>> To give a better idea of problem (1), I have attached two jpegs. They >>> were made by doing a screen capture within Inkscape while zoomed to >>> 800%. They are labeled before and after and show the effects of >>> scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG >>> files were created using Stefan's "Print Image in SVG Format." Other >>> printing plug-ins may already be implementing their own solutions. >>> >>> regards, >>> Larry Becker >>> >>> On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: Larry, This is a great post. Thanks
Re: [JPP-Devel] Rendering problems affecting the quality of printing
I would be interested in the perceptual limit. Our users typically produce maps for limited distribution in two different formats: DXF and PDF. It also may be printed on either a standard printer or a large size plotter in order to study it more closely or prepare for a meeting with a client. The advantage of the DXF distribution is that it can be opened in free CAD viewers which have exact measurement tools. The advantage of the PDF is that it is ready to print and everyone understands it. The disadvantage of PDF is its limited usefulness for viewing on screen. Zooming is limited and graphics tend to look "chuncky" and imprecise. This is why I am trying to improve the printing quality to PDF. The current output looks somewhat unprofessional. regards, Larry On 7/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > > The only thing that will make the SVG look different will > > be a different styling. The right sizes of the graphical > > attributes must have a physical measure. The output medium > > has to have a physical measure. Than you can determine the > > right scales. > > do you think that is possible? Since every printer has his own physical > limits one probably needs to look for the printer settings... a bit > tricky for different platforms? (ok.. at the end there is always a > rastering, if one does not use pen-plotters..., so a solution may be to > let the user define a DPI value in *JUMP). > The other thing i can remark is that the human has perceptual limits to > see something. I can post this minimum "mm" thresholds teached in > cartography if somebody is interested. > > stefan > > > > > What we need is a concept of a physical size based output device. > > Renderers must be aware of this. This leads to a lot of refactoring. > > As an alternative we can build a complete new rendering path, > > which has to be consistent with the old one. WYSIWYG is another > > word that comes to mind. What if someone add a new Layerable with > > new Renderers? Should she or he implement the same logic twice? > > > > - Sascha > > > > Sunburned Surveyor schrieb: > >> Larry, > >> > >> I know it is very easy to convert to SVG by using the JTS graphics > >> painted on the LayerViewPanel and the Batik libs. > >> > >> I wonder if some of the problems could be eliminated by using the JTS > >> Goemetries and Layer styling information to convert directly to SVG. > >> > >> Just a thought. > >> > >> The Sunburned Surveyor > >> > >> On 6/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: > >>> More surprises (for me). Someone stop me if this is already > >>> documented. If you set the line width to zero, you get very faint > >>> lines. The documentation for BasicStroke says, "If width is set to > >>> 0.0f, the stroke is rendered as the thinnest possible line for the > >>> target device and the antialias hint setting." > >>> > >>> Apparently when you create a new layer, the line width defaults to 1. > >>> I never noticed that you could drag it left to 0, or if I did I must > >>> have assumed it was an error. > >>> > >>> This could be very handy when you are printing and the lines are > >>> showing up too wide on the print device, or just when you have a lot > >>> of linestrings very close together. > >>> > >>> regards, > >>> Larry > >>> > >>> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > Interesting... It turns out that when rendering antialiased lines, > Java2D actually draws lines with fractional widths as shown in the > attached JumpWindow screen capture. This would make it possible to > modify the Change Style line width slider to support floating point > values that represent very thin lines. > > Larry > > On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > To give a better idea of problem (1), I have attached two jpegs. They > > were made by doing a screen capture within Inkscape while zoomed to > > 800%. They are labeled before and after and show the effects of > > scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG > > files were created using Stefan's "Print Image in SVG Format." Other > > printing plug-ins may already be implementing their own solutions. > > > > regards, > > Larry Becker > > > > On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > >> Larry, > >> > >> This is a great post. Thanks for documenting some of the problems we > >> are having with the rendering system. Perhaps I need to take a crack > >> at these with my pluggable renderering system, instead of stand alone > >> labels. I'll give this some thought. > >> > >> The Sunburned Surveyor > >> > >> On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: > >>> The purpose of this thread is to document problems with BasicStyle > >>> rendering that primarily affect the quality of printing plug-ins > >>> > >>> Problem (1): > >>> > >>> BasicStyle lineStroke d
Re: [JPP-Devel] Rendering problems affecting the quality of printing
The unit for line width is defined by the graphics system - so 1 = 1 pt. = 1/72 of an inch (or metric equivalent). Larry On 7/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > > Larry Becker schrieb: > > Hi Stefan, > > > > We still may wish to change the UI so that it is possible to set > > fractional line widths as is possible in other programs. > ok. > > > That would > > require more refactoring. It depends on how much control users need. > > Such capability is always included in programs like Illustrator, and > > is commonly used when printing maps. If I understand you correctly, > > you are using Illustrator or Inkscape to set the correct line widths > > before printing, yes? > > yes i use these (rather illustrator) > note that illustrator offers: 0.25pt, 0.5pt, 0.75pt and 1.0pt > > so i would suggest to have such fixed values too? and not a purely free > choice. but.. these are pt-values (making sense for printers). What is > actually the "unit" used for BasicStyle? > > stefan > > > > > regards, > > Larry > > > > On 7/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > >> A very late response to Larry: > >> > >> so, do you think that your modification of the BasicStyle constructor is > >> now obsolete, since we can use "0" > >> > >> BTW... I am exporting in svg and then prepare my images in > >> illustrator(inkscape). Thus, i don't really have styling problems. but > >> who has the time to do like i do. > >> > >> Larry Becker schrieb: > >>> More surprises (for me). Someone stop me if this is already > >>> documented. If you set the line width to zero, you get very faint > >>> lines. The documentation for BasicStroke says, "If width is set to > >>> 0.0f, the stroke is rendered as the thinnest possible line for the > >>> target device and the antialias hint setting." > >>> > >>> Apparently when you create a new layer, the line width defaults to 1. > >>> I never noticed that you could drag it left to 0, or if I did I must > >>> have assumed it was an error. > >>> > >>> This could be very handy when you are printing and the lines are > >>> showing up too wide on the print device, or just when you have a lot > >>> of linestrings very close together. > >>> > >>> regards, > >>> Larry > >>> > >>> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > Interesting... It turns out that when rendering antialiased lines, > Java2D actually draws lines with fractional widths as shown in the > attached JumpWindow screen capture. This would make it possible to > modify the Change Style line width slider to support floating point > values that represent very thin lines. > > Larry > > On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > To give a better idea of problem (1), I have attached two jpegs. They > > were made by doing a screen capture within Inkscape while zoomed to > > 800%. They are labeled before and after and show the effects of > > scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG > > files were created using Stefan's "Print Image in SVG Format." Other > > printing plug-ins may already be implementing their own solutions. > > > > regards, > > Larry Becker > > > > On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > >> Larry, > >> > >> This is a great post. Thanks for documenting some of the problems we > >> are having with the rendering system. Perhaps I need to take a crack > >> at these with my pluggable renderering system, instead of stand alone > >> labels. I'll give this some thought. > >> > >> The Sunburned Surveyor > >> > >> On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: > >>> The purpose of this thread is to document problems with BasicStyle > >>> rendering that primarily affect the quality of printing plug-ins > >>> > >>> Problem (1): > >>> > >>> BasicStyle lineStroke defaults to width 1. See Geoff's "About Line > >>> Decorations and Printing" thread in the archives: > >>> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html > >>> > >>> Proposed solution (1.A): > >>> > >>> The problem seems to me that JUMP is starting out with the line width > >>> way too large. In other applications I have used much smaller default > >>> line widths. In order to do this we would need to modify > >>> BasicStyle.setLineWidth(int lineWidth) to use a float instead of an > >>> int and change setLineWidth(1) to setLineWidth(0.1) or something > >>> smaller in the constructor. > >>> > >>> > >>> Problem (2): > >>> > >>> The relative scale of symbols and text changes when changing from > >>> screen resolution to printer resolution. See Geoff's ""Re: > >>> [JPP-Devel] JumpPrinter" thread in the archives: > >>> http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html > >>> > >>> Proposed solution (2.A): > >
Re: [JPP-Devel] Rendering problems affecting the quality of printing
Larry Becker schrieb: > Hi Stefan, > > We still may wish to change the UI so that it is possible to set > fractional line widths as is possible in other programs. ok. > That would > require more refactoring. It depends on how much control users need. > Such capability is always included in programs like Illustrator, and > is commonly used when printing maps. If I understand you correctly, > you are using Illustrator or Inkscape to set the correct line widths > before printing, yes? yes i use these (rather illustrator) note that illustrator offers: 0.25pt, 0.5pt, 0.75pt and 1.0pt so i would suggest to have such fixed values too? and not a purely free choice. but.. these are pt-values (making sense for printers). What is actually the "unit" used for BasicStyle? stefan > > regards, > Larry > > On 7/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: >> A very late response to Larry: >> >> so, do you think that your modification of the BasicStyle constructor is >> now obsolete, since we can use "0" >> >> BTW... I am exporting in svg and then prepare my images in >> illustrator(inkscape). Thus, i don't really have styling problems. but >> who has the time to do like i do. >> >> Larry Becker schrieb: >>> More surprises (for me). Someone stop me if this is already >>> documented. If you set the line width to zero, you get very faint >>> lines. The documentation for BasicStroke says, "If width is set to >>> 0.0f, the stroke is rendered as the thinnest possible line for the >>> target device and the antialias hint setting." >>> >>> Apparently when you create a new layer, the line width defaults to 1. >>> I never noticed that you could drag it left to 0, or if I did I must >>> have assumed it was an error. >>> >>> This could be very handy when you are printing and the lines are >>> showing up too wide on the print device, or just when you have a lot >>> of linestrings very close together. >>> >>> regards, >>> Larry >>> >>> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: Interesting... It turns out that when rendering antialiased lines, Java2D actually draws lines with fractional widths as shown in the attached JumpWindow screen capture. This would make it possible to modify the Change Style line width slider to support floating point values that represent very thin lines. Larry On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > To give a better idea of problem (1), I have attached two jpegs. They > were made by doing a screen capture within Inkscape while zoomed to > 800%. They are labeled before and after and show the effects of > scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG > files were created using Stefan's "Print Image in SVG Format." Other > printing plug-ins may already be implementing their own solutions. > > regards, > Larry Becker > > On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: >> Larry, >> >> This is a great post. Thanks for documenting some of the problems we >> are having with the rendering system. Perhaps I need to take a crack >> at these with my pluggable renderering system, instead of stand alone >> labels. I'll give this some thought. >> >> The Sunburned Surveyor >> >> On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: >>> The purpose of this thread is to document problems with BasicStyle >>> rendering that primarily affect the quality of printing plug-ins >>> >>> Problem (1): >>> >>> BasicStyle lineStroke defaults to width 1. See Geoff's "About Line >>> Decorations and Printing" thread in the archives: >>> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html >>> >>> Proposed solution (1.A): >>> >>> The problem seems to me that JUMP is starting out with the line width >>> way too large. In other applications I have used much smaller default >>> line widths. In order to do this we would need to modify >>> BasicStyle.setLineWidth(int lineWidth) to use a float instead of an >>> int and change setLineWidth(1) to setLineWidth(0.1) or something >>> smaller in the constructor. >>> >>> >>> Problem (2): >>> >>> The relative scale of symbols and text changes when changing from >>> screen resolution to printer resolution. See Geoff's ""Re: >>> [JPP-Devel] JumpPrinter" thread in the archives: >>> http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html >>> >>> Proposed solution (2.A): >>> >>> I haven't thought this one through very well, but it would seem that >>> we need to have some sort of renderer DPI setting (there's those pesky >>> english units again). Unfortunately there doesn't seem to be any >>> Java2D support for this concept that I could find, so we would >>> probably have to implement the scaling ourselves. Someone else may >>> hav
Re: [JPP-Devel] Rendering problems affecting the quality of printing
Hi Stefan, We still may wish to change the UI so that it is possible to set fractional line widths as is possible in other programs. That would require more refactoring. It depends on how much control users need. Such capability is always included in programs like Illustrator, and is commonly used when printing maps. If I understand you correctly, you are using Illustrator or Inkscape to set the correct line widths before printing, yes? regards, Larry On 7/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > A very late response to Larry: > > so, do you think that your modification of the BasicStyle constructor is > now obsolete, since we can use "0" > > BTW... I am exporting in svg and then prepare my images in > illustrator(inkscape). Thus, i don't really have styling problems. but > who has the time to do like i do. > > Larry Becker schrieb: > > More surprises (for me). Someone stop me if this is already > > documented. If you set the line width to zero, you get very faint > > lines. The documentation for BasicStroke says, "If width is set to > > 0.0f, the stroke is rendered as the thinnest possible line for the > > target device and the antialias hint setting." > > > > Apparently when you create a new layer, the line width defaults to 1. > > I never noticed that you could drag it left to 0, or if I did I must > > have assumed it was an error. > > > > This could be very handy when you are printing and the lines are > > showing up too wide on the print device, or just when you have a lot > > of linestrings very close together. > > > > regards, > > Larry > > > > On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > >> Interesting... It turns out that when rendering antialiased lines, > >> Java2D actually draws lines with fractional widths as shown in the > >> attached JumpWindow screen capture. This would make it possible to > >> modify the Change Style line width slider to support floating point > >> values that represent very thin lines. > >> > >> Larry > >> > >> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > >>> To give a better idea of problem (1), I have attached two jpegs. They > >>> were made by doing a screen capture within Inkscape while zoomed to > >>> 800%. They are labeled before and after and show the effects of > >>> scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG > >>> files were created using Stefan's "Print Image in SVG Format." Other > >>> printing plug-ins may already be implementing their own solutions. > >>> > >>> regards, > >>> Larry Becker > >>> > >>> On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Larry, > > This is a great post. Thanks for documenting some of the problems we > are having with the rendering system. Perhaps I need to take a crack > at these with my pluggable renderering system, instead of stand alone > labels. I'll give this some thought. > > The Sunburned Surveyor > > On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > The purpose of this thread is to document problems with BasicStyle > > rendering that primarily affect the quality of printing plug-ins > > > > Problem (1): > > > > BasicStyle lineStroke defaults to width 1. See Geoff's "About Line > > Decorations and Printing" thread in the archives: > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html > > > > Proposed solution (1.A): > > > > The problem seems to me that JUMP is starting out with the line width > > way too large. In other applications I have used much smaller default > > line widths. In order to do this we would need to modify > > BasicStyle.setLineWidth(int lineWidth) to use a float instead of an > > int and change setLineWidth(1) to setLineWidth(0.1) or something > > smaller in the constructor. > > > > > > Problem (2): > > > > The relative scale of symbols and text changes when changing from > > screen resolution to printer resolution. See Geoff's ""Re: > > [JPP-Devel] JumpPrinter" thread in the archives: > > http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html > > > > Proposed solution (2.A): > > > > I haven't thought this one through very well, but it would seem that > > we need to have some sort of renderer DPI setting (there's those pesky > > english units again). Unfortunately there doesn't seem to be any > > Java2D support for this concept that I could find, so we would > > probably have to implement the scaling ourselves. Someone else may > > have already thought of a better solution. > > > > There are probably other printer related rendering problems I haven't > > heard about. > > > > regards, > > Larry Becker > > > > -- > > http://amusingprogrammer.blogspot.com/ > > > > - > > This SF.
Re: [JPP-Devel] Rendering problems affecting the quality of printing
> The only thing that will make the SVG look different will > be a different styling. The right sizes of the graphical > attributes must have a physical measure. The output medium > has to have a physical measure. Than you can determine the > right scales. do you think that is possible? Since every printer has his own physical limits one probably needs to look for the printer settings... a bit tricky for different platforms? (ok.. at the end there is always a rastering, if one does not use pen-plotters..., so a solution may be to let the user define a DPI value in *JUMP). The other thing i can remark is that the human has perceptual limits to see something. I can post this minimum "mm" thresholds teached in cartography if somebody is interested. stefan > > What we need is a concept of a physical size based output device. > Renderers must be aware of this. This leads to a lot of refactoring. > As an alternative we can build a complete new rendering path, > which has to be consistent with the old one. WYSIWYG is another > word that comes to mind. What if someone add a new Layerable with > new Renderers? Should she or he implement the same logic twice? > > - Sascha > > Sunburned Surveyor schrieb: >> Larry, >> >> I know it is very easy to convert to SVG by using the JTS graphics >> painted on the LayerViewPanel and the Batik libs. >> >> I wonder if some of the problems could be eliminated by using the JTS >> Goemetries and Layer styling information to convert directly to SVG. >> >> Just a thought. >> >> The Sunburned Surveyor >> >> On 6/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: >>> More surprises (for me). Someone stop me if this is already >>> documented. If you set the line width to zero, you get very faint >>> lines. The documentation for BasicStroke says, "If width is set to >>> 0.0f, the stroke is rendered as the thinnest possible line for the >>> target device and the antialias hint setting." >>> >>> Apparently when you create a new layer, the line width defaults to 1. >>> I never noticed that you could drag it left to 0, or if I did I must >>> have assumed it was an error. >>> >>> This could be very handy when you are printing and the lines are >>> showing up too wide on the print device, or just when you have a lot >>> of linestrings very close together. >>> >>> regards, >>> Larry >>> >>> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: Interesting... It turns out that when rendering antialiased lines, Java2D actually draws lines with fractional widths as shown in the attached JumpWindow screen capture. This would make it possible to modify the Change Style line width slider to support floating point values that represent very thin lines. Larry On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > To give a better idea of problem (1), I have attached two jpegs. They > were made by doing a screen capture within Inkscape while zoomed to > 800%. They are labeled before and after and show the effects of > scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG > files were created using Stefan's "Print Image in SVG Format." Other > printing plug-ins may already be implementing their own solutions. > > regards, > Larry Becker > > On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: >> Larry, >> >> This is a great post. Thanks for documenting some of the problems we >> are having with the rendering system. Perhaps I need to take a crack >> at these with my pluggable renderering system, instead of stand alone >> labels. I'll give this some thought. >> >> The Sunburned Surveyor >> >> On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: >>> The purpose of this thread is to document problems with BasicStyle >>> rendering that primarily affect the quality of printing plug-ins >>> >>> Problem (1): >>> >>> BasicStyle lineStroke defaults to width 1. See Geoff's "About Line >>> Decorations and Printing" thread in the archives: >>> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html >>> >>> Proposed solution (1.A): >>> >>> The problem seems to me that JUMP is starting out with the line width >>> way too large. In other applications I have used much smaller default >>> line widths. In order to do this we would need to modify >>> BasicStyle.setLineWidth(int lineWidth) to use a float instead of an >>> int and change setLineWidth(1) to setLineWidth(0.1) or something >>> smaller in the constructor. >>> >>> >>> Problem (2): >>> >>> The relative scale of symbols and text changes when changing from >>> screen resolution to printer resolution. See Geoff's ""Re: >>> [JPP-Devel] JumpPrinter" thread in the archives: >>> http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html >>> >>> Proposed solution (2.A): >>> >
Re: [JPP-Devel] Rendering problems affecting the quality of printing
A very late response to Larry: so, do you think that your modification of the BasicStyle constructor is now obsolete, since we can use "0" BTW... I am exporting in svg and then prepare my images in illustrator(inkscape). Thus, i don't really have styling problems. but who has the time to do like i do. Larry Becker schrieb: > More surprises (for me). Someone stop me if this is already > documented. If you set the line width to zero, you get very faint > lines. The documentation for BasicStroke says, "If width is set to > 0.0f, the stroke is rendered as the thinnest possible line for the > target device and the antialias hint setting." > > Apparently when you create a new layer, the line width defaults to 1. > I never noticed that you could drag it left to 0, or if I did I must > have assumed it was an error. > > This could be very handy when you are printing and the lines are > showing up too wide on the print device, or just when you have a lot > of linestrings very close together. > > regards, > Larry > > On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: >> Interesting... It turns out that when rendering antialiased lines, >> Java2D actually draws lines with fractional widths as shown in the >> attached JumpWindow screen capture. This would make it possible to >> modify the Change Style line width slider to support floating point >> values that represent very thin lines. >> >> Larry >> >> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: >>> To give a better idea of problem (1), I have attached two jpegs. They >>> were made by doing a screen capture within Inkscape while zoomed to >>> 800%. They are labeled before and after and show the effects of >>> scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG >>> files were created using Stefan's "Print Image in SVG Format." Other >>> printing plug-ins may already be implementing their own solutions. >>> >>> regards, >>> Larry Becker >>> >>> On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: Larry, This is a great post. Thanks for documenting some of the problems we are having with the rendering system. Perhaps I need to take a crack at these with my pluggable renderering system, instead of stand alone labels. I'll give this some thought. The Sunburned Surveyor On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: > The purpose of this thread is to document problems with BasicStyle > rendering that primarily affect the quality of printing plug-ins > > Problem (1): > > BasicStyle lineStroke defaults to width 1. See Geoff's "About Line > Decorations and Printing" thread in the archives: > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html > > Proposed solution (1.A): > > The problem seems to me that JUMP is starting out with the line width > way too large. In other applications I have used much smaller default > line widths. In order to do this we would need to modify > BasicStyle.setLineWidth(int lineWidth) to use a float instead of an > int and change setLineWidth(1) to setLineWidth(0.1) or something > smaller in the constructor. > > > Problem (2): > > The relative scale of symbols and text changes when changing from > screen resolution to printer resolution. See Geoff's ""Re: > [JPP-Devel] JumpPrinter" thread in the archives: > http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html > > Proposed solution (2.A): > > I haven't thought this one through very well, but it would seem that > we need to have some sort of renderer DPI setting (there's those pesky > english units again). Unfortunately there doesn't seem to be any > Java2D support for this concept that I could find, so we would > probably have to implement the scaling ourselves. Someone else may > have already thought of a better solution. > > There are probably other printer related rendering problems I haven't > heard about. > > regards, > Larry Becker > > -- > http://amusingprogrammer.blogspot.com/ > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sou
Re: [JPP-Devel] Rendering problems affecting the quality of printing
@Larry: IIRC the zero policy was introduced by Sun as a reaction to some user complains at bugs.sun.com that lines were vanishing when the scale becomes very small. I can't remember when that was done. Before 1.4? @SS: What do you think does Batik? It simply creates elements from g2d.lineTo(new Line.Double(..)) calls and same for other geometries. There is no magic in there. These primitives are generated by a Java2DConverter which takes a JTS geometry as an input. In pure terms of geometry they are identical! Okay .. at the moment they are piped through Larry's decimating Java2DConverter, but I'm going to check-in the PreciseJava2DConverter from the Print/Layout plug-in as temporal replacement (see Viewport.setJava2DConverter()). This will improve Stefan's SVG plug-in. The only thing that will make the SVG look different will be a different styling. The right sizes of the graphical attributes must have a physical measure. The output medium has to have a physical measure. Than you can determine the right scales. What we need is a concept of a physical size based output device. Renderers must be aware of this. This leads to a lot of refactoring. As an alternative we can build a complete new rendering path, which has to be consistent with the old one. WYSIWYG is another word that comes to mind. What if someone add a new Layerable with new Renderers? Should she or he implement the same logic twice? - Sascha Sunburned Surveyor schrieb: > Larry, > > I know it is very easy to convert to SVG by using the JTS graphics > painted on the LayerViewPanel and the Batik libs. > > I wonder if some of the problems could be eliminated by using the JTS > Goemetries and Layer styling information to convert directly to SVG. > > Just a thought. > > The Sunburned Surveyor > > On 6/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: >> More surprises (for me). Someone stop me if this is already >> documented. If you set the line width to zero, you get very faint >> lines. The documentation for BasicStroke says, "If width is set to >> 0.0f, the stroke is rendered as the thinnest possible line for the >> target device and the antialias hint setting." >> >> Apparently when you create a new layer, the line width defaults to 1. >> I never noticed that you could drag it left to 0, or if I did I must >> have assumed it was an error. >> >> This could be very handy when you are printing and the lines are >> showing up too wide on the print device, or just when you have a lot >> of linestrings very close together. >> >> regards, >> Larry >> >> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: >>> Interesting... It turns out that when rendering antialiased lines, >>> Java2D actually draws lines with fractional widths as shown in the >>> attached JumpWindow screen capture. This would make it possible to >>> modify the Change Style line width slider to support floating point >>> values that represent very thin lines. >>> >>> Larry >>> >>> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: To give a better idea of problem (1), I have attached two jpegs. They were made by doing a screen capture within Inkscape while zoomed to 800%. They are labeled before and after and show the effects of scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG files were created using Stefan's "Print Image in SVG Format." Other printing plug-ins may already be implementing their own solutions. regards, Larry Becker On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Larry, > > This is a great post. Thanks for documenting some of the problems we > are having with the rendering system. Perhaps I need to take a crack > at these with my pluggable renderering system, instead of stand alone > labels. I'll give this some thought. > > The Sunburned Surveyor > > On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: >> The purpose of this thread is to document problems with BasicStyle >> rendering that primarily affect the quality of printing plug-ins >> >> Problem (1): >> >> BasicStyle lineStroke defaults to width 1. See Geoff's "About Line >> Decorations and Printing" thread in the archives: >> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html >> >> Proposed solution (1.A): >> >> The problem seems to me that JUMP is starting out with the line width >> way too large. In other applications I have used much smaller default >> line widths. In order to do this we would need to modify >> BasicStyle.setLineWidth(int lineWidth) to use a float instead of an >> int and change setLineWidth(1) to setLineWidth(0.1) or something >> smaller in the constructor. >> >> >> Problem (2): >> >> The relative scale of symbols and text changes when changing from >> screen resolution to printer resolution. See Geoff's ""Re: >> [JPP-Devel] JumpPr
Re: [JPP-Devel] Rendering problems affecting the quality of printing
Larry, I know it is very easy to convert to SVG by using the JTS graphics painted on the LayerViewPanel and the Batik libs. I wonder if some of the problems could be eliminated by using the JTS Goemetries and Layer styling information to convert directly to SVG. Just a thought. The Sunburned Surveyor On 6/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: > More surprises (for me). Someone stop me if this is already > documented. If you set the line width to zero, you get very faint > lines. The documentation for BasicStroke says, "If width is set to > 0.0f, the stroke is rendered as the thinnest possible line for the > target device and the antialias hint setting." > > Apparently when you create a new layer, the line width defaults to 1. > I never noticed that you could drag it left to 0, or if I did I must > have assumed it was an error. > > This could be very handy when you are printing and the lines are > showing up too wide on the print device, or just when you have a lot > of linestrings very close together. > > regards, > Larry > > On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > Interesting... It turns out that when rendering antialiased lines, > > Java2D actually draws lines with fractional widths as shown in the > > attached JumpWindow screen capture. This would make it possible to > > modify the Change Style line width slider to support floating point > > values that represent very thin lines. > > > > Larry > > > > On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > To give a better idea of problem (1), I have attached two jpegs. They > > > were made by doing a screen capture within Inkscape while zoomed to > > > 800%. They are labeled before and after and show the effects of > > > scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG > > > files were created using Stefan's "Print Image in SVG Format." Other > > > printing plug-ins may already be implementing their own solutions. > > > > > > regards, > > > Larry Becker > > > > > > On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > > > Larry, > > > > > > > > This is a great post. Thanks for documenting some of the problems we > > > > are having with the rendering system. Perhaps I need to take a crack > > > > at these with my pluggable renderering system, instead of stand alone > > > > labels. I'll give this some thought. > > > > > > > > The Sunburned Surveyor > > > > > > > > On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > > > The purpose of this thread is to document problems with BasicStyle > > > > > rendering that primarily affect the quality of printing plug-ins > > > > > > > > > > Problem (1): > > > > > > > > > > BasicStyle lineStroke defaults to width 1. See Geoff's "About Line > > > > > Decorations and Printing" thread in the archives: > > > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html > > > > > > > > > > Proposed solution (1.A): > > > > > > > > > > The problem seems to me that JUMP is starting out with the line width > > > > > way too large. In other applications I have used much smaller default > > > > > line widths. In order to do this we would need to modify > > > > > BasicStyle.setLineWidth(int lineWidth) to use a float instead of an > > > > > int and change setLineWidth(1) to setLineWidth(0.1) or something > > > > > smaller in the constructor. > > > > > > > > > > > > > > > Problem (2): > > > > > > > > > > The relative scale of symbols and text changes when changing from > > > > > screen resolution to printer resolution. See Geoff's ""Re: > > > > > [JPP-Devel] JumpPrinter" thread in the archives: > > > > > http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html > > > > > > > > > > Proposed solution (2.A): > > > > > > > > > > I haven't thought this one through very well, but it would seem that > > > > > we need to have some sort of renderer DPI setting (there's those pesky > > > > > english units again). Unfortunately there doesn't seem to be any > > > > > Java2D support for this concept that I could find, so we would > > > > > probably have to implement the scaling ourselves. Someone else may > > > > > have already thought of a better solution. > > > > > > > > > > There are probably other printer related rendering problems I haven't > > > > > heard about. > > > > > > > > > > regards, > > > > > Larry Becker > > > > > > > > > > -- > > > > > http://amusingprogrammer.blogspot.com/ > > > > > > > > > > - > > > > > This SF.net email is sponsored by DB2 Express > > > > > Download DB2 Express C - the FREE version of DB2 express and take > > > > > control of your XML. No limits. Just data. Click to get it now. > > > > > http://sourceforge.net/powerbar/db2/ > > > > > ___ > > > > > Jump-pilot-devel mailing list > > > > > Jump-pilot-devel@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-de
Re: [JPP-Devel] Rendering problems affecting the quality of printing
More surprises (for me). Someone stop me if this is already documented. If you set the line width to zero, you get very faint lines. The documentation for BasicStroke says, "If width is set to 0.0f, the stroke is rendered as the thinnest possible line for the target device and the antialias hint setting." Apparently when you create a new layer, the line width defaults to 1. I never noticed that you could drag it left to 0, or if I did I must have assumed it was an error. This could be very handy when you are printing and the lines are showing up too wide on the print device, or just when you have a lot of linestrings very close together. regards, Larry On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > Interesting... It turns out that when rendering antialiased lines, > Java2D actually draws lines with fractional widths as shown in the > attached JumpWindow screen capture. This would make it possible to > modify the Change Style line width slider to support floating point > values that represent very thin lines. > > Larry > > On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > To give a better idea of problem (1), I have attached two jpegs. They > > were made by doing a screen capture within Inkscape while zoomed to > > 800%. They are labeled before and after and show the effects of > > scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG > > files were created using Stefan's "Print Image in SVG Format." Other > > printing plug-ins may already be implementing their own solutions. > > > > regards, > > Larry Becker > > > > On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > > Larry, > > > > > > This is a great post. Thanks for documenting some of the problems we > > > are having with the rendering system. Perhaps I need to take a crack > > > at these with my pluggable renderering system, instead of stand alone > > > labels. I'll give this some thought. > > > > > > The Sunburned Surveyor > > > > > > On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > > The purpose of this thread is to document problems with BasicStyle > > > > rendering that primarily affect the quality of printing plug-ins > > > > > > > > Problem (1): > > > > > > > > BasicStyle lineStroke defaults to width 1. See Geoff's "About Line > > > > Decorations and Printing" thread in the archives: > > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html > > > > > > > > Proposed solution (1.A): > > > > > > > > The problem seems to me that JUMP is starting out with the line width > > > > way too large. In other applications I have used much smaller default > > > > line widths. In order to do this we would need to modify > > > > BasicStyle.setLineWidth(int lineWidth) to use a float instead of an > > > > int and change setLineWidth(1) to setLineWidth(0.1) or something > > > > smaller in the constructor. > > > > > > > > > > > > Problem (2): > > > > > > > > The relative scale of symbols and text changes when changing from > > > > screen resolution to printer resolution. See Geoff's ""Re: > > > > [JPP-Devel] JumpPrinter" thread in the archives: > > > > http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html > > > > > > > > Proposed solution (2.A): > > > > > > > > I haven't thought this one through very well, but it would seem that > > > > we need to have some sort of renderer DPI setting (there's those pesky > > > > english units again). Unfortunately there doesn't seem to be any > > > > Java2D support for this concept that I could find, so we would > > > > probably have to implement the scaling ourselves. Someone else may > > > > have already thought of a better solution. > > > > > > > > There are probably other printer related rendering problems I haven't > > > > heard about. > > > > > > > > regards, > > > > Larry Becker > > > > > > > > -- > > > > http://amusingprogrammer.blogspot.com/ > > > > > > > > - > > > > This SF.net email is sponsored by DB2 Express > > > > Download DB2 Express C - the FREE version of DB2 express and take > > > > control of your XML. No limits. Just data. Click to get it now. > > > > http://sourceforge.net/powerbar/db2/ > > > > ___ > > > > Jump-pilot-devel mailing list > > > > Jump-pilot-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > > - > > > This SF.net email is sponsored by DB2 Express > > > Download DB2 Express C - the FREE version of DB2 express and take > > > control of your XML. No limits. Just data. Click to get it now. > > > http://sourceforge.net/powerbar/db2/ > > > ___ > > > Jump-pilot-devel mailing list > > > Jump-pilot-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > -
Re: [JPP-Devel] Rendering problems affecting the quality of printing
Interesting... It turns out that when rendering antialiased lines, Java2D actually draws lines with fractional widths as shown in the attached JumpWindow screen capture. This would make it possible to modify the Change Style line width slider to support floating point values that represent very thin lines. Larry On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: To give a better idea of problem (1), I have attached two jpegs. They were made by doing a screen capture within Inkscape while zoomed to 800%. They are labeled before and after and show the effects of scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG files were created using Stefan's "Print Image in SVG Format." Other printing plug-ins may already be implementing their own solutions. regards, Larry Becker On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Larry, > > This is a great post. Thanks for documenting some of the problems we > are having with the rendering system. Perhaps I need to take a crack > at these with my pluggable renderering system, instead of stand alone > labels. I'll give this some thought. > > The Sunburned Surveyor > > On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > The purpose of this thread is to document problems with BasicStyle > > rendering that primarily affect the quality of printing plug-ins > > > > Problem (1): > > > > BasicStyle lineStroke defaults to width 1. See Geoff's "About Line > > Decorations and Printing" thread in the archives: > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html > > > > Proposed solution (1.A): > > > > The problem seems to me that JUMP is starting out with the line width > > way too large. In other applications I have used much smaller default > > line widths. In order to do this we would need to modify > > BasicStyle.setLineWidth(int lineWidth) to use a float instead of an > > int and change setLineWidth(1) to setLineWidth(0.1) or something > > smaller in the constructor. > > > > > > Problem (2): > > > > The relative scale of symbols and text changes when changing from > > screen resolution to printer resolution. See Geoff's ""Re: > > [JPP-Devel] JumpPrinter" thread in the archives: > > http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html > > > > Proposed solution (2.A): > > > > I haven't thought this one through very well, but it would seem that > > we need to have some sort of renderer DPI setting (there's those pesky > > english units again). Unfortunately there doesn't seem to be any > > Java2D support for this concept that I could find, so we would > > probably have to implement the scaling ourselves. Someone else may > > have already thought of a better solution. > > > > There are probably other printer related rendering problems I haven't > > heard about. > > > > regards, > > Larry Becker > > > > -- > > http://amusingprogrammer.blogspot.com/ > > > > - > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > ___ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- http://amusingprogrammer.blogspot.com/ -- http://amusingprogrammer.blogspot.com/ <><>- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Rendering problems affecting the quality of printing
Larry, This is a great post. Thanks for documenting some of the problems we are having with the rendering system. Perhaps I need to take a crack at these with my pluggable renderering system, instead of stand alone labels. I'll give this some thought. The Sunburned Surveyor On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: > The purpose of this thread is to document problems with BasicStyle > rendering that primarily affect the quality of printing plug-ins > > Problem (1): > > BasicStyle lineStroke defaults to width 1. See Geoff's "About Line > Decorations and Printing" thread in the archives: > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html > > Proposed solution (1.A): > > The problem seems to me that JUMP is starting out with the line width > way too large. In other applications I have used much smaller default > line widths. In order to do this we would need to modify > BasicStyle.setLineWidth(int lineWidth) to use a float instead of an > int and change setLineWidth(1) to setLineWidth(0.1) or something > smaller in the constructor. > > > Problem (2): > > The relative scale of symbols and text changes when changing from > screen resolution to printer resolution. See Geoff's ""Re: > [JPP-Devel] JumpPrinter" thread in the archives: > http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html > > Proposed solution (2.A): > > I haven't thought this one through very well, but it would seem that > we need to have some sort of renderer DPI setting (there's those pesky > english units again). Unfortunately there doesn't seem to be any > Java2D support for this concept that I could find, so we would > probably have to implement the scaling ourselves. Someone else may > have already thought of a better solution. > > There are probably other printer related rendering problems I haven't > heard about. > > regards, > Larry Becker > > -- > http://amusingprogrammer.blogspot.com/ > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Rendering problems affecting the quality of printing
The purpose of this thread is to document problems with BasicStyle rendering that primarily affect the quality of printing plug-ins Problem (1): BasicStyle lineStroke defaults to width 1. See Geoff's "About Line Decorations and Printing" thread in the archives: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html Proposed solution (1.A): The problem seems to me that JUMP is starting out with the line width way too large. In other applications I have used much smaller default line widths. In order to do this we would need to modify BasicStyle.setLineWidth(int lineWidth) to use a float instead of an int and change setLineWidth(1) to setLineWidth(0.1) or something smaller in the constructor. Problem (2): The relative scale of symbols and text changes when changing from screen resolution to printer resolution. See Geoff's ""Re: [JPP-Devel] JumpPrinter" thread in the archives: http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html Proposed solution (2.A): I haven't thought this one through very well, but it would seem that we need to have some sort of renderer DPI setting (there's those pesky english units again). Unfortunately there doesn't seem to be any Java2D support for this concept that I could find, so we would probably have to implement the scaling ourselves. Someone else may have already thought of a better solution. There are probably other printer related rendering problems I haven't heard about. regards, Larry Becker -- http://amusingprogrammer.blogspot.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
