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 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 >> > > ------------------------------------------------------------------------- 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
