diff options
Diffstat (limited to 'Master/xemtex/doc/ghostscript/Projects.htm')
-rw-r--r-- | Master/xemtex/doc/ghostscript/Projects.htm | 629 |
1 files changed, 629 insertions, 0 deletions
diff --git a/Master/xemtex/doc/ghostscript/Projects.htm b/Master/xemtex/doc/ghostscript/Projects.htm new file mode 100644 index 00000000000..3ee7f5cad5f --- /dev/null +++ b/Master/xemtex/doc/ghostscript/Projects.htm @@ -0,0 +1,629 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html> +<head> +<title>Ghostscript projects</title> +<!-- $Id: Projects.htm,v 1.33.2.11.2.6 2003/05/17 14:39:00 giles Exp $ --> +<link rel="stylesheet" type="text/css" href="gs.css" title="Ghostscript Style"> +</head> + +<body> +<!-- [1.0 begin visible header] ============================================ --> + +<!-- [1.1 begin headline] ================================================== --> + +<h1>Ghostscript projects seeking developers</h1> + +<!-- [1.1 end headline] ==================================================== --> + +<!-- [1.2 begin table of contents] ========================================= --> + +<h2>Table of contents</h2> + +<ul> +<li><a href="#Platforms">Platforms</a> +<li><a href="#Driver_architecture">Driver architecture</a> +<li><a href="#Specific_drivers">Specific drivers</a> +<li><a href="#Graphics_functionality">Graphics functionality</a> +<li><a href="#Performance">Performance</a> +<li><a href="#Other_functionality">Other functionality</a> +<li><a href="#Other_implementation">Implementation improvements</a> +</ul> + +<!-- [1.2 end table of contents] =========================================== --> + +<!-- [1.3 begin hint] ====================================================== --> + +<p>For other information, see the <a href="Readme.htm">Ghostscript +overview</a>. + +<!-- [1.3 end hint] ======================================================== --> + +<hr> + +<!-- [1.0 end visible header] ============================================== --> + +<!-- [2.0 begin contents] ================================================== --> + +<p> +There are many projects that would improve Ghostscript and that we would +like to do, but for which we don't have enough resources. If you would like +to take responsibility for any of these projects, please <a +href="mailto:raph@artofcode.com">contact us</a>. Additional comments on +implementation approaches or project goals are in <I>italic type like +this</I>. + +<h2><a name="Platforms"></a>Additional platforms</h2> + +<h3>DOS, Windows and OS/2 builds using gcc.</h3> + +<p> +We would like Ghostscript to work with the free <b><tt>emx/gcc</tt></b> and +<b><tt>rsx</tt></b> libraries, to provide an alternative DOS, Windows +95/98/NT, and OS/2 implementation that requires no proprietary, commercial +compilers. We think Ghostscript's existing OS/2 makefile already includes +most of what is needed. If someone is willing to do the work, we will be +happy to include this in our list of supported platforms and to distribute +the makefiles. + +<h3>Windows driver using Ghostscript as a language monitor.</h3> + +<p> +MS Windows has a "language monitor" capability which would allow Ghostscript +to be invoked seamlessly to process input files in any language Ghostscript +could handle (currently PostScript and PDF) and for any printer for which +Ghostscript had a driver. Doing this properly would require integrating +Ghostscript with Windows' "Add Printer" dialog, and would also require +creating a PPD for Ghostscript. <I>Russell Lang's RedMon program provides +some, but not all, of this capability.</I> + +<h3>Netscape browser plug-in.</h3> + +<p> +Currently, Ghostscript can work as a "helper application" for the Netscape +browser, but not as a plug-in; the latter would integrate it more closely +with the browser. We aren't sure what doing this would involve; we've also +heard by rumor that it's already been done. + +<h3>Ghostscript as an Active-X COM Object.</h3> + +<p> +In order to integrate Ghostscript into XMetaL and other applications it +would be convenient for Ghostscript to be distributed as a COM object +along with the current gswin32.exe, gswin32c.exe and gsdll32.dll files. + +<hr> + +<h2><a name="Driver_architecture"></a>Driver Architecture</h2> + +<h3>Improved multi-threaded rendering support.</h3> + +<p> +Currently, drivers can be written so that converting PostScript to a list of +graphical objects can run in one thread, and rasterizing the objects can run +in another thread. However, drivers must be written specially if they are +going to do this. We would like to change the architecture so that any +driver can work this way. We would also like to support dual-threaded +operation for drivers that produce high-level output, such as the PDF +writer. <I>Doing this would require separating banding from +the multithreaded logic. Also, currently each thread has its own allocation +pool: this is unnecessary in the normal case, since Ghostscript now supports +properly locked access to the C heap, but embedded systems still need to use +a fixed-size area for the rasterizing thread. With a locked, shared +allocator, the rasterizing thread could use the full set of band list +functions; with a fixed-size area and a separate allocator, only a subset is +available, as is the case now for dual-threaded drivers. +</I> + +<h3>Dynamic run-time loadable devices.</h3> + +<p> +Currently, drivers must be linked into the executable. We would like to be +able to load drivers dynamically. Doing this requires defining a +platform-independent API (presumably extending the current gp_* APIs) that +would work at least on GNU/Linux, vendor Unix, MS Windows, and Macintosh. Unix +systems should include Sun, HP, AIX, IRIX, DEC; Linux ELF and a.out formats +should both be supported. <I>Consider the Netscape plug-in +architecture.</I> + +<h3>Moving 'setpagedevice' into C.</h3> + +<p> +The PostScript 'setpagedevice' function implements matching of media and +page size requests to available media, page orientation, and paper handling +(duplex, etc.) Currently it is implemented in PostScript code, which means +it is not available for use with other input languages. (It is available +for PDF, which Ghostscript implements on top of PostScript, but not for the +not-yet-freely-available PCL interpreters that use the Ghostscript library, +or for possible future SVG or similar interpreters). We would like to move +this function into C. <I>The device driver will be required to +send page parameters up to PostScript to be stored in a resource. To be +included in this project are handling policy implementations in the device +drivers. DeferredMediaSelection should also be implemented.</I> + +<h3>Adding 'tee' for output to multiple devices.</h3> + +<p> +In a few cases, it would be desirable to provide a 'tee' capability for +drivers: specifically, for generating small, low-resolution 'thumbnail' +images concurrently with other output. <I>Probably the +simplest way to do this is to generate a band list and then process it +twice. This is not completely trivial, since the band list does include +device resolution information and scaling would be required for some +constructs.</I> + +<h3><b><tt>OutputDevice</tt></b> resource category</h3> + +<p> +Each available output device should provide an instance of the +<b><tt>OutputDevice</tt></b> resource category, which gives the available +page sizes, resolutions, media classes, process color models, and other +information about the device. <I>This would replace the current +non-standard use of a 4-element <b><tt>PageSize</tt></b> in the +<b><tt>InputAttributes</tt></b> entry of the page device dictionary.</I> + +<h3>Removing the limit on the length of OutputFile.</h3> + +<p> +Currently, the maximum length of the <b><tt>OutputFile</tt></b> parameter is +a compile-time constant, <b><tt>gp_file_name_sizeof</tt></b>. This is +appropriate for ordinary file names, since this constant is the platform's +limit on the length of a file name. However, if <b><tt>OutputFile</tt></b> +is a pipe, the length should not be limited in this way. <I>This is +probably a small project: it requires allocating the file name dynamically, +and freeing it in the finalization routine that gets called when a driver +instance is freed.</I>. + +<h2><a name="Specific_drivers"></a>Specific drivers</h2> + +<h3>PrintGear and PPA output drivers.</h3> + +<p> +We would like to provide (Adobe) PrintGear and (H-P) PPA output drivers for +Ghostscript, but the specifications for these protocols are not published. +If you can provide them to us without violating any agreements, please let +us know. (Some work has already been done on reverse-engineering these +protocols, but we don't have references to it.) + +<h3>Improve 'pswrite' up to the level of 'pdfwrite'.</h3> + +<p> +We would like to improve the high-level PostScript-writing +<b><tt>pswrite</tt></b> driver to bring it up to parity with the PDF-writing +driver (including the many improvements in the latter being implemented in +Ghostscript 7.xx). Specifically, we want it to write text as text rather +than bitmaps, and to consistently write images in their original high-level +form. <I>We have already started to factor out code that +should be common to these two drivers, specifically for writing embedded +fonts and compressed data streams.</I> + +<p> +There is one small part of this project that would be especially valuable +and could be done independently (although it might have to be partly or +entirely redone later): compressing images. Currently the driver only +compresses character bitmaps, and doesn't compress other images at all. +<I>It should use the <b><tt>CCITTFaxEncode</tt></b> filter for 1-bit-deep +images, and plane-separated <b><tt>LZWEncode</tt></b> compression for color +images, using the <b><tt>miGIF</tt></b> algorithms that are believed to be +free of the Welch patent for the latter. When generating LL3 PS, the +<b><tt>Flate</tt></b> compression will work better than miGIF. It may be +worth trying several methods on each image and use the one that works best.</I> + +<h3>High level graphics and text for PCL 5 and PCL XL drivers.</h3> + +<p> +Currently, the PCL 5 drivers produce only bitmaps; the PCL XL driver +produces high-level graphics and sometimes high-level images, but low-level +text. We would like to improve these drivers to produce higher-level, +smaller output. <I>This was a very low-priority project; it has become more +important now that H-P's laser printers are shipping with less memory.</I> + +<h3>Improved high level GDI driver for Windows.</h3> + +<p> +We would like a "GDI driver" for MS Windows that would implement more +higher-level constructs (specifically for text). <I> The +<b><tt>mswin</tt></b> and <b><tt>mswinprn</tt></b> drivers both do some of +this. Some of the the 'xfont' support code for MS Windows should be useful. +We were frustrated in the past because the GDI calls for getting font sizes +and metrics consistently returned incorrect information and provided no way +to get the correct information; perhaps this has been fixed in 32-bit +Windows. We believe that H-P, Russell Lang, and perhaps others are working +in this area, but we can always use more help.</I> + +<h3>PDF thumbnail generation.</h3> + +<p> +The PDF writer needs to be able to generate thumbnails (small previews). We +might do this through the 'tee' capability mentioned above. However, we +currently prefer the idea of implementing a completely separate program to +add thumbnails to an arbitrary, existing PDF file: this would allow +Ghostscript to add thumbnails to PDF files generated by other programs. +<I>Much of the code needed to do this has already been written +for Ghostscript's PDF linearizer: see +<b><tt>lib/pdfwrite.ps</tt></b>. A user has implemented this as well, +using a separate program that calls Ghostscript: see +<a href="http://www.uni-giessen.de/~g029/eurotex99/oberdiek/"> +http://www.uni-giessen.de/~g029/eurotex99/oberdiek/</a>. +</I> + +<h3>Consolidate inkjet drivers into a single family.</h3> + +<p> +In addition to factoring out the error diffusion code as described below, we +would like to see another attempt at reducing the enormous volume of code +for color inkjet drivers. There are three sets of drivers (gdevcdj.c, +gdevstc.c, gdevupd.c) with much overlapping functionality. The latter two +driver families make good attempts at factoring out things like head +geometry and canned control strings, but we think this problem deserves +another pass, especially in the hope of consolidating these drivers into a +single family. + +<h3>Download glyph bitmaps (with glyph decaching notification).</h3> + +<p> +See below under "Notification for glyph decaching." + +<h3>Preserve compression when writing PDF images.</h3> + +<p> +Currently, all images are decompressed by the interpreter before being +passed to the graphics library; the PDF writer may then compress them again. +Ordinarily, this only slows things down a little, but in the case of +DCT-encoded images that are being DCT-encoded in the output, image +degradation may occur. Ideally, the implementation should be smart enough +to not decode and re-encode the image. However, making this work properly +is difficult. <I>This would probably involve extending the library APIs for +images so that they could pass a stream, possibly including filters, instead +of the (fully decoded) data rows.</I> + +<hr> + +<h2><a name="Graphics_functionality"></a>Graphics functionality</h2> + +<h3>Support for 64-bit colors on 64-bit platforms.</h3> + +<p> +Currently, the library supports a maximum of 32 bits of data per pixel; we +would like to raise this limit to 64 bits on systems where the 'long' data +type is 64 bits wide. <I>The <b><tt>gx_color_index</tt></b> +type is already defined as 'long', but there are many places where the type +<b><tt>bits32</tt></b> is used for pixel values; there is a 32-bit +stored-image "device", but there is no 64-bit device; a few algorithms and +tables have knowledge of the 32-bit width built into them, only because the +C preprocessor doesn't have any kind of loop or repetition +capability.</I> + +<h3>In-RIP trapping.</h3> + +<p> +The PostScript specification includes an option for the interpreter to +implement trapping (adjustments of object boundaries to prevent visual +anomalies caused by slight misregistration of different ink layers): we +would like to implement this. <I>This is a complex and +difficult area; even many Adobe RIPs don't do it.</I> + +<h3>Hook FreeType TrueType library into graphics library.</h3> + +<p> +We would like to provide an option for good integration of the FreeType font +rasterizer into Ghostscript, since the FreeType code is better than +Ghostscript's current rasterizers. We understand that some users in Japan +have done this already, but we don't know if this is a good starting point +(the only documentation is in Japanese). <I>Their work uses +Ghostscript's 'xfont' interface, which is how Ghostscript interfaces to +platform facilities such as the X and MS Windows font capabilities. This is +a device-level interface and not the best place to do this: we would rather +have the graphics library interface to FreeType directly.</I> + +<h3>ICC profile support for output.</h3> + +<p> +Ghostscript 7.00 and later supports ICCBased color spaces of PDF +using the icclib package from +<a href="http://web.access.net.au/argyll/color.html "> +http://web.access.net.au/argyll/color.html</a> +but there is no facility to use ICC output (printer) profiles that +may be embedded in the PDF. Also it would be useful for PostScript +to be able to directly use a specific Intent from ICC profile to +convert output colors (as CRD's are now used). +<I>The primary difficulty is that the graphics library and PostScript +always use CIE XYZ as the connection space, but ICC profiles may +use CIELAB as the connection space, requiring conversion for use +with the graphics library. </I> + +<h3>Making halftones into "objects" and adding new types.</h3> + +<p> +Currently, knowledge of the specific data formats and algorithms for +halftoning permeates too many places in the library. We would like +halftoning to be more "object oriented" (using virtual procedures) so that +we could support other halftoning methods such as direct use of threshold +arrays, or the double-rectangle approach added in newer PostScript versions. +<I>Threshold arrays take much less space than the current +representation, generally at the expense of longer rendering time for +black-and-white images; double-rectangle representation would give us a +better implementation of AccurateScreens. We might want store both +threshold arrays and the current representation.</I> + +<h3>Factor out error diffusion routines, integrate ETS.</h3> + +<p> +Currently, several different inkjet drivers implement their own, very +similar but slightly differing error diffusion methods. This has caused +severe code bloat as well as tempting future driver writers to contribute to +it further. We want to factor out error diffusion into a common set of +facilities that drivers can use. <I>We would like to design +these facilities so that they can easily interface to the Even-Toned +Screening algorithms from artofcode (Raph Levien), to the extent that these +will be Open Source.</I> + +<h3>Improve, or generalize, linearization for stochastic threshold +data.</h3> + +<p> +The Ghostscript distribution includes a stochastic threshold array. This +array has some gamma correction built into it, which works well for some +output devices and not for others. We would like to provide a version of +this array without (or with less) gamma correction. <I>We have +original data available from which this could be done fairly easily.</I> + +<h3>Change sampled functions to use new interpreted functions.</h3> + +<p> +The PostScript language defines many functions relevant to graphics +rendering as being implemented by arbitrary PostScript procedures: transfer +(gamma correction), black generation, undercolor removal, several stages of +CIE color space and rendering, and color mapping for Separation and DeviceN +spaces. Since the graphics library can't call PostScript procedures, +Ghostscript currently samples these procedures at a fixed number of points +and interpolates linearly between the samples. As of Ghostscript 6.20, the +library can interpret a restricted subset of PostScript procedures directly +(basically those that only use arithmetic and comparisons: no loops, +sub-procedures, or data structures). Changing the rendering functions to +use this approach when possible would greatly improve output quality when +the functions are very non-linear (which we have actually seen in practice). +<I>This should only be done if the function is, in fact, +severely non-linear, since interpreting the function definition will almost +always be much slower than interpolating in the table.</I> + +<h3>Add optional cubic interpolation to RenderTable and other table +lookup.</h3> + +<p> +Currently, if a CIE rendering dictionary uses a lookup table for the final +step, Ghostscript always interpolates linearly between the entries. Cubic +interpolation should be supported as an option. A cubic interpolation +option is also needed for general table-lookup Functions. + +<h3>Add better (SVG-like) alpha channel and compositing to library.</h3> + +<p> +Ghostscript has partial support for alpha channel and for alpha and RasterOp +compositing. There is some architectural support for general compositing, +but it postdates the RasterOp implementation, and most of the RasterOp code +doesn't use it. We expect that the more extensive compositing and alpha +capabilities of SVG will find their way into PDF (and probably PostScript as +well) in the course of 2000 and 2001, and we will need to implement them. + +<hr> + +<h2><a name="Performance"></a>Performance</h2> + +<h3>Change band list logic to defer halftoning until rendering.</h3> + +<p> +Currently, when Ghostscript uses a band list, it does halftoning before +banding. It should do halftoning after banding: this produces smaller band +lists and shifts more work to the rasterizer (which is good because the +rasterizer can be multi-threaded internally for higher performance on +multiprocessors: see the next topic.) + +<h3>Reduce redundant data for smoothed banded images.</h3> + +<p> +When smoothed ("interpolated") images are written in the band list, extra +rows must be written above and below each band in order to provide the data +for interpolation. Currently, the number of such rows is computed very +conservatively; instead, the final interpolation algorithm should be +consulted to provide the correct value. <i>This is a small task.</i> + +<h3>Multi-threaded rasterizing</h3> + +<p> +For high-resolution devices, rasterization dominates execution time. On +multiprocessor systems, Ghostscript can do tasks in parallel: + +<ul> + +<li>Rasterize multiple bands simultaneously; + +<li>Rasterize multiple color planes of a single band simultaneously (if a +planar representation is being used); + +<li>For some computation-intensive tasks like smoothing images or filling +large regions, partition the task (possibly buffering more data to allow +larger-grain partitioning) and execute several partitions simultaneously. + +</ul> + +<p> +We would want these facilities implemented so that no conditional +compilation was involved: on uniprocessor systems, the locking API would +simply have a vacuous implementation. + +<h3>Notification for glyph decaching.</h3> + +<p> +Currently, drivers can't do a very good job of downloading rendered +character bitmaps to the device they manage, because they can't find out +when a bitmap is being deleted from Ghostscript's cache and therefore will +never be referenced again. Here is a sketch of how we would add this +capability to the graphics library: + +<ul> + +<li>The driver would implement the <b><tt>text_begin</tt></b> call, simply +to get access to a <b><tt>gs_imager_state</tt></b> that references the +rendered character cache. (The driver could always simply call the default +implementation of <b><tt>text_begin</tt></b>.) + +<li>In the <b><tt>text_begin</tt></b> procedure, the driver would call + +<blockquote><pre> +gs_glyph_decache_register(imager_state, notify_proc, proc_data) +</pre></blockquote> + +<p> +where <b><tt>proc_data</tt></b> was, or pointed to a structure that +included, a pointer to the driver. + +<li><b><tt>gs_glyph_decache_register</tt></b> would use the general +notification mechanism defined in <b><tt>gsnotify.h</tt></b> to call + +<blockquote><pre> +notify_proc(proc_data, pchar_data) +</pre></blockquote> + +<p> +whenever a bitmap was removed from the character cache. +<b><tt>pchar_data</tt></b> would point to some identification of the +character; perhaps just the bitmap ID, but possibly a +<b><tt>gx_cached_bits_common</tt></b> or even a <b><tt>cached_char</tt></b>. + +<li>The <b><tt>char_cache</tt></b> structure would be need an additional +member, a <b><tt>gs_notify_list_t</tt></b>. It would also need to add +finalization so that when it was freed, it would notify and unregister all +clients, using <b><tt>gs_notify_all(list, NULL)</tt></b> and then +<b><tt>gs_notify_release</tt></b>. + +</ul> + +<p> +<I>This facility was requested by the Display Ghostscript project, but it +could also be used to improve the output of the PCL XL driver and possibly +the X and PCL5 drivers.</I> + +<hr> + +<h2><a name="Other_functionality"></a>Other functionality</h2> + +<h3>OpenStep (Display PostScript + NeXT) extensions to Ghostscript.</h3> + +<p> +There is a project to create a GNU implementation of the OPENStep API, which +involves extending Ghostscript to provide the full functionality of Adobe's +Display PostScript system with some of the NeXT extensions. For more +information, please contact Net-Community <<a +href="mailto:scottc@net-community.com">scottc@net-community.com</a>>. + +<h3>Job Server implementation.</h3> + +<p> +For full Adobe PostScript compatibility, Ghostscript needs a real "job +server" to encapsulate the execution of PostScript files. +<I>See the section on "Job Execution Environment" in the PostScript +Language Reference Manual for details.</I> + +<h3>SVG (XML Structured Vector Graphics) interpreter.</h3> + +<p> +Ghostscript could be adapted with some work to read SVG. This would be an +interesting and challenging project because SVG's graphics model would +require extending the library (see above). <I>If SVG turns out to be an +important standard, it is important that there be a good free implementation +of it.</I> + +<h3><b><tt>%font%</tt></b> and other IODevices.</h3> + +<p> +Currently, the <b><tt>%font%</tt></b> IODevice is not implemented. We would +like to see this implemented using a general framework for implementing +IODevices (%xxxx%) entirely in PostScript, in an "object oriented" manner +very similiar to the way Resource categories are implemented. An IODevice +would be implemented as a dictionary with the following keys, whose values +would be procedures that implemented the corresponding operation: + +<blockquote><pre> +/File +/DeleteFile +/RenameFile +/Status +/FileNameForAll +/GetDevParams +/PutDevParams +</pre></blockquote> + +<p> +There would only be global IODevices, no local ones; the dictionary keeping +track of them would be stored in global VM. + +<p> +<I>This is an obscure feature that matters only because some PostScript code +uses <b><tt>filenameforall</tt></b> with this IODevice, rather than +<b><tt>filenameforall</tt></b> with the <b><tt>/Font</tt></b> Resource +category, to enumerate available fonts.</I> + +<h3>Repairing damaged or EOL-converted PDF files.</h3> + +<p> +Adobe Acrobat Reader can scan a PDF file that has had its end-of-lines +converted by careless users transferring the file across operating systems +as text rather than binary across, and reconstruct the cross-reference table +which the PDF interpreter requires. This only works if the file has no +binary data in it, which with PDF 1.3 is rarely the case. However, users +occasionally receive PDF files that have been damaged in this way, and it +might be useful to have a program that can repair them. <I>We think this +should probably be done as a separate program, possibly in PostScript, +similar to Ghostscript's PDF linearizer.</I> + +<h2><a name="Other_implementation"></a>Implementation improvements</h2> + +<h3>Fully re-entrant code.</h3> + +<p> +Currently, neither the PostScript interpreter nor the graphics library is +fully re-entrant (no writable globals). Making them fully re-entrant would +make Ghostscript usable in multi-threaded environments, and more easily +usable in embedded environments. Note that this is necessary, but far from +sufficient, for Ghostscript to allow simultaneous execution of a single +Ghostscript interpreter instance by multiple threads: that is probably +permanently out of the question. <I>Almost all drivers, including all of +the drivers in devs.mak which are maintained as part of the main Ghostscript +code, are already fully re-entrant; making the remaining ones re-entrant +should really be up to the driver author.</I> + +<h3>Ghostscript has no %ram% device.</h3> + +The %ram% device is documented in PS Supplement 3010 and 3011 dated August 30, 1999. +This is probably not a major impediment to portability, but it would be handy. +<p><I> +On Unix, the suggested implementation would be to create a subdirectory +of the temporary directory (usually /tmp), with the name chosen and the +directory created in such a way as to avoid /tmp races and similar +problems. Ghostscript should delete the subdirectory when it exits. +</I> + +<!-- [2.0 end contents] ==================================================== --> + +<!-- [3.0 begin visible trailer] =========================================== --> +<hr> + +<p> +<small>Copyright © 2000 Aladdin Enterprises. All rights +reserved.</small> + +<p> +This software is provided AS-IS with no warranty, either express or +implied. + +This software is distributed under license and may not be copied, +modified or distributed except as expressly authorized under the terms +of the license contained in the file LICENSE in this distribution. + +<p> +<small>Ghostscript version 7.07, 17 May 2003 + +<!-- [3.0 end visible trailer] ============================================= --> + +</body> +</html> |