Could you explain why W3M is needed on Solaris. The FastTrack doesn't seem to indicate what need it fills. Dan has suggested elinks is a better text-based web browser. Did we consider elinks? What made us want to integrate w3m instead of other alternatives?
Brian Shi-Ying Irene Huang wrote: > Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > W3M > 1.2. Name of Document Author/Supplier: > Author: Rick Ju > 1.3 Date of This Document: > 27 May, 2008 > 4. Technical Description > 1. Introduction > 1.1. Project/Component Working Name: > > w3m a text-based WWW browser > > 1.2. Name of Document Author/Supplier: > > Author: Rick Ju > Sponser: Irene Huang > > 1.3. Date of This Document: > > 05/11/2008 > > 2. Technical Description: > 2.1. Details: > > w3m is a text-based web browser as well as a pager like `more' or `less'. > With w3m you can browse web pages through a terminal emulator window > (xterm, rxvt or something like that). Moreover, w3m can be used as a > text formatting tool which typesets HTML into plain text. > > w3m has support for tables, frames, SSL connections, color and even > inline > images on suitable terminals. Generally, it renders pages in a form as > true > to their original layout as possible. And W3m is small. Its stripped > binary for Sparc is only 260kbyte. > > w3m locally run cgi scripts to test html output (requires *no* > webserver). > w3m keystroke compatible with lynx and support the keybindings customize. > w3m support SSL through the openssl library. And w3m could support > cookies. > > Table rendering algorithm in w3m > > HTML table rendering is difficult. Tabular environment of LaTeX is not > very > difficult, which makes the width of a column either a specified value or > the maximum width to put items into it. On the other hand, HTML table > renderer has to decide the width of a column so that the entire table can > fit into the display appropriately, and fold the contents of the table > according to the column width. Inappropriate column width decision makes > the table ugly. Moreover, table can be nested, which makes the algorithm > more complicated. > > 1. First, calculate the maximum and minimum width of each column. The > maximum width is the width required to display the column without > folding the contents. Generally, it is the length of paragraph > delimited by <BR> or <P>. The minimum width is the lower limit > to display the contents. If the column contains the word > `internationalization', the minimum width will be 20. If the column > contains <pre>..</pre>, the maximum width of the preformatted > text will be the minimum width of the column. 2. If the width of > the column is specified by WIDTH attribute, fix the column > width using that value. If the specified width is smaller than the > minimum width of the column, fix the column width to the minimum > width. > > 3. Calculate the sum of the maximum width (or fixed width) of each column > and check if the sum exceeds the screen width. If it is smaller than > screen width, these values are used for width of each column. > > 4. If the sum is larger than the screen width, determine the widths of > each column according to the following steps. > 1. Let W be the screen width subtracted by the sum of widths of > fixed-width columns. > 2. Distribute W into the columns whose width are not decided, in > proportion to the logarithm of the maximum width of each column. > 3. If the distributed width of a column is smaller than the minimum > width, then fix the width of the column to the minimum width, > and do the distribution again. > > In this process, distributed width is proportion to logarithm of maximum > width. > > The algorithm above assumes that the screen width is known. But it is not > true for nested table. According the algorithm above, the column width of > the outer table have to be known to render the inner table, while the > total > width of the inner table have to be known to determine the column width of > the outer table. If WIDTH attribute exists there are no problems. > Otherwise, w3m assumes that the inner table is 0.8 times as wide as the > outer table. It works fine, but if there are two tables side by side in an > outer table, the width of the outer table always exceeds the screen width. > To render this kind of table correctly, one have to render the table once, > check the width of outmost table, and then render the entire table again. > Netscape might employ this kind of algorithm. > > 2.2. Interfaces: > Exported Interfaces > Interface Classification Comments > --------------- --------------- ----------------------- > w3m CLI Volatile See w3m-help.txt > > $HOME/.w3m/config Project Private w3m Configuration > information > SUNWw3m Uncommited w3m end-user packaging > contains binary, libraries. > SUNWw3m-l10n Uncommited Localization. > > Imported Interfaces > Interface Classification Comments > --------------- --------------- ----------------------- > HTML/XML/HTTP Stable These specs are defined > W 3C.org > OpenSSL Volatile PSARC/2003/500 > Firefox Volatile LSARC/2008/158 > GTK+ Committed LSARC/2006/202 > libpng Volatile LSARC/2006/202 > > 2.3. Doc Impact: > > Man page is needed. > > 2.4. Packaging & Delivery: > SUNWw3m (base package) - application i.e binary, > libraries > SUNWw3m-l10n (localization) - Localization. > > > 2.5. Dependencies: > w3m depends on OpenSSL, Firefox, GTK+, and libpng. > > 2.6. L10N Impact: > There are string changes. Hence this should be taken care. > > 2.7 Security Impact: > > None. > > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > Desktop > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org
