From owner-p4-projects@FreeBSD.ORG Mon Apr 23 16:14:36 2012 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id A28D51065670; Mon, 23 Apr 2012 16:14:35 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 647C5106566B for ; Mon, 23 Apr 2012 16:14:35 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from skunkworks.freebsd.org (skunkworks.freebsd.org [IPv6:2001:4f8:fff6::2d]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0048FC16 for ; Mon, 23 Apr 2012 16:14:35 +0000 (UTC) Received: from skunkworks.freebsd.org (localhost [127.0.0.1]) by skunkworks.freebsd.org (8.14.4/8.14.4) with ESMTP id q3NGEZE4048705 for ; Mon, 23 Apr 2012 16:14:35 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.4/8.14.4/Submit) id q3NGEYe4048702 for perforce@freebsd.org; Mon, 23 Apr 2012 16:14:34 GMT (envelope-from rene@FreeBSD.org) Date: Mon, 23 Apr 2012 16:14:34 GMT Message-Id: <201204231614.q3NGEYe4048702@skunkworks.freebsd.org> X-Authentication-Warning: skunkworks.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Precedence: bulk Cc: Subject: PERFORCE change 210076 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:14:36 -0000 http://p4web.freebsd.org/@@210076?ac=10 Change 210076 by rene@rene_acer on 2012/04/23 16:14:07 IFC Affected files ... .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/committers-guide/article.sgml#54 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml#137 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributors/contrib.committers.sgml#82 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/releng/Makefile#4 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/releng/article.sgml#11 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/fdp-primer/see-also/chapter.sgml#3 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml#7 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml#45 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/porters-handbook/book.sgml#138 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/share/sgml/authors.ent#75 integrate .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/config/chapter.sgml#42 integrate .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/introduction/chapter.sgml#37 integrate .. //depot/projects/docproj_nl/share/images/articles/releng/branches-head.pic#2 integrate .. //depot/projects/docproj_nl/share/images/articles/releng/branches-releng8.pic#3 integrate .. //depot/projects/docproj_nl/share/images/articles/releng/branches-releng9.pic#1 branch .. //depot/projects/docproj_nl/share/pgpkeys/jlh.key#1 branch .. //depot/projects/docproj_nl/share/pgpkeys/pgpkeys-developers.sgml#75 integrate .. //depot/projects/docproj_nl/share/pgpkeys/pgpkeys.ent#72 integrate .. //depot/projects/docproj_nl/share/sgml/freebsd.ent#28 integrate .. //depot/projects/docproj_nl/www/en/advocacy/index.sgml#5 integrate .. //depot/projects/docproj_nl/www/en/cgi/man.cgi#28 integrate .. //depot/projects/docproj_nl/www/en/community/social.xsl#6 integrate .. //depot/projects/docproj_nl/www/en/developers.sgml#75 integrate .. //depot/projects/docproj_nl/www/en/platforms/index.sgml#2 integrate .. //depot/projects/docproj_nl/www/en/projects/newbies.sgml#7 integrate .. //depot/projects/docproj_nl/www/en/releases/8.3R/Makefile#3 integrate .. //depot/projects/docproj_nl/www/en/releases/8.3R/announce.sgml#1 branch .. //depot/projects/docproj_nl/www/en/releases/8.3R/installation.html#1 branch .. //depot/projects/docproj_nl/www/en/releases/8.3R/relnotes.sgml#1 branch .. //depot/projects/docproj_nl/www/en/releases/index.sgml#16 integrate .. //depot/projects/docproj_nl/www/en/search/web.atoz#10 integrate .. //depot/projects/docproj_nl/www/en/security/security.sgml#22 integrate .. //depot/projects/docproj_nl/www/share/sgml/news.xml#140 integrate .. //depot/projects/docproj_nl/www/share/sgml/press.xml#23 integrate .. //depot/projects/docproj_nl/www/share/sgml/release.ent#46 integrate Differences ... ==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/committers-guide/article.sgml#54 (text+ko) ==== @@ -9,7 +9,7 @@ The &os; Documentation Project - $FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.317 2012/04/03 12:07:47 gavin Exp $ + $FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.318 2012/04/18 19:23:55 bcr Exp $ 1999 @@ -2143,6 +2143,267 @@ + Vendor imports with <acronym>SVN</acronym> + + + Please read this entire section before starting a vendor + import. + + + + Patches to vendor code fall into two categories: + + + + Vendor patches: these are patches that have been + issued by the vendor, or that have been extracted from + the vendor's version control system, which address + issues which in your opinion can't wait until the next + vendor release. + + + &os; patches: these are patches that modify the + vendor code to address &os;-specific issues. + + + + The nature of a patch dictates where it should be + committed: + + + + Vendor patches should be committed to the vendor + branch, and merged from there to head. If the patch + addresses an issue in a new release that is currently + being imported, it must not be + committed along with the new release: the release must + be imported and tagged first, then the patch can be + applied and committed. There is no need to re-tag the + vendor sources after committing the patch. + + + &os; patches should be committed directly to + head. + + + + + + Preparing the tree + + If importing for the first time after the switch to + Subversion, flattening and cleaning up the vendor tree is + necessary, as well as bootstrapping the merge history in + the main tree. + + + Flattening + + During the conversion from CVS to + Subversion, vendor branches were imported with the same + layout as the main tree. This means that the + pf vendor sources ended up in + vendor/pf/dist/contrib/pf. The + vendor source is best directly in + vendor/pf/dist. + + To flatten the pf tree: + + &prompt.user; cd vendor/pf/dist/contrib/pf +&prompt.user; svn mv $(svn list) ../.. +&prompt.user; cd ../.. +&prompt.user; svn rm contrib +&prompt.user; svn propdel -R svn:mergeinfo . +&prompt.user; svn commit + + The propdel bit is necessary + because starting with 1.5, Subversion will automatically + add svn:mergeinfo to any directory + that is copied or moved. In this case, as nothing is + being merged from the deleted tree, they just get in the + way. + + Tags may be flattened as well (3, 4, 3.5 etc.); the + procedure is exactly the same, only changing + dist to 3.5 or + similar, and putting the svn commit + off until the end of the process. + + + Cleaning up + + The dist tree can be cleaned up + as necessary. Disabling keyword expansion is + recommended, as it makes no sense on unmodified vendor + code and in some cases it can even be harmful. + OpenSSH, for example, includes + two files that originated with &os; and still contain the + original version tags. To do this: + + &prompt.user; svn propdel svn:keywords -R . +&prompt.root; svn commit + + + Bootstrapping merge history + + If importing for the first time after the switch to + Subversion, bootstrapping + svn:mergeinfo on the target directory + in the main tree to the to the revision that corresponds + to the last related change to the vendor tree, prior to + importing new sources: + + &prompt.user; cd head/contrib/pf +&prompt.user; svn merge --record-only svn+ssh://svn.freebsd.org/base/vendor/pf/dist@180876 . +&prompt.user; svn commit + + + + + Importing new sources + + With two commits—one for the import itself and + one for the tag—this step can optionally be repeated + for every upstream release between the last import and the + current import. + + + Preparing the vendor sources + + Unlike in CVS where only the needed + parts were imported into the vendor tree to avoid bloating + the main tree, Subversion is able to store a full + distribution in the vendor tree. So, import everything, + but merge only what is required. + + A svn add is required to add any + files that were added since the last vendor import, and + svn rm is required to remove any that + were removed since. Preparing sorted lists of the + contents of the vendor tree and of the sources that are + about to be imported is recommended, to facilitate the + process. + + &prompt.user; cd vendor/pf/dist +&prompt.user; svn list -R | grep -v '/$' | sort >../old +&prompt.user; cd ../pf-4.3 +&prompt.user; find . -type f | cut -c 3- | sort >../new + + With these two files, + comm -23 ../old ../new + will list removed files (files only in + old), while + comm -13 ../old ../new + will list added files only in new. + + + Importing into the vendor tree + + Now, the sources must be copied into + dist and + the svn add and + svn rm commands should be used as + needed: + + &prompt.user; cd vendor/pf/pf-4.3 +&prompt.user; tar cf - . | tar xf - -C ../dist +&prompt.user; cd ../dist +&prompt.user; comm -23 ../old ../new | xargs svn rm +&prompt.user; comm -13 ../old ../new | xargs svn --parents add + + If any directories were removed, they will have to be + svn rmed manually. Nothing will break + if they are not, but they will remain in the tree. + + Check properties on any new files. All text files + should have svn:eol-style set to + native. All binary files should have + svn:mime-type set to + application/octet-stream unless there + is a more appropriate media type. Executable files should + have svn:executable set to + *. No other properties should exist + on any file in the tree. + + Committing is now possible, however it is good + practice to make sure that everything is OK by using the + svn stat and + svn diff commands. + + + Tagging + + Once committed, vendor releases should be tagged for + future reference. The best and quickest way to do this + is directly in the repository: + + &prompt.user; svn cp svn+ssh://svn.freebsd.org/base/vendor/pf/dist svn+ssh://svn.freebsd.org/base/vendor/pf/4.3 + + Once that is complete, svn up the + working copy of + vendor/pf + to get the new tag, although this is rarely + needed. + + If creating the tag in the working copy of the tree, + svn:mergeinfo results must be removed: + + &prompt.user; cd vendor/pf +&prompt.user; svn cp dist 4.3 +&prompt.user; svn propdel svn:mergeinfo -R 4.3 + + + + Merging to head + + &prompt.user; cd head/contrib/pf +&prompt.user; svn up +&prompt.user; svn merge --accept=postpone svn+ssh://svn.freebsd.org/base/vendor/pf/dist . + + The --accept=postpone tells + Subversion that it shouldn't complain because merge conflicts + will be taken care of manually. + + It is necessary to resolve any merge conflicts. + This process is the same in SVN as in + CVS. + + Make sure that any files that were added or removed in + the vendor tree have been properly added or removed in the + main tree. To check diffs against the vendor branch: + + &prompt.user; svn diff --no-diff-deleted --old=svn+ssh://svn.freebsd.org/base/vendor/pf/dist --new=. + + The --no-diff-deleted tells + Subversion not to complain about files that are in the + vendor tree but not in the main tree, i.e. things that + would have previously been removed before the vendor + import, like for example the like the vendor's makefiles + and configure scripts. + + Using CVS, once a file was off the + vendor branch, it was not able to be put back. With + Subversion, there is no concept of on or off the vendor + branch. If a file that previously had local + modifications, to make it not show up in diffs in the + vendor tree, all that has to be done is remove any left-over + cruft like &os; version tags, which is much easier. + + If any changes are required for the world to build + with the new sources, make them now, and keep testing + until everything builds and runs perfectly. + + + Committing the vendor import + + Committing is now possible! Everything must be + committed in one go. If done properly, the tree will move + from a consistent state with old code, to a consistent + state with new code. + + + + Reverting a Commit Reverting a commit to a previous version is fairly ==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml#137 (text+ko) ==== @@ -1,4 +1,4 @@ - + + See Also - This document is deliberately not an exhaustive discussion of SGML, - the DTDs listed, and the FreeBSD Documentation Project. For more - information about these, you are encouraged to see the following web - sites. + This document is deliberately not an exhaustive discussion of + SGML, the DTDs listed, and the FreeBSD Documentation Project. For + more information about these, you are encouraged to see the + following web sites. The FreeBSD Documentation Project @@ -48,7 +48,8 @@ - The FreeBSD Handbook + The FreeBSD + Handbook @@ -58,13 +59,15 @@ - The SGML/XML web - page, a comprehensive SGML resource + The + SGML/XML web page, a comprehensive SGML + resource - + Gentle introduction to SGML + url="http://www-sul.stanford.edu/tools/tutorials/html2.0/gentle.html">Gentle + introduction to SGML @@ -79,8 +82,8 @@ - The HTML 4.0 - specification + The HTML + 4.0 specification @@ -90,21 +93,21 @@ - The DocBook - Technical Committee, maintainers of the DocBook DTD + The + DocBook Technical Committee, maintainers of the + DocBook DTD - DocBook: The Definitive - Guide, the online documentation for the DocBook - DTD - + DocBook: The + Definitive Guide, the online documentation for the + DocBook DTD - The DocBook Open - Repository contains DSSSL stylesheets and other resources - for people using DocBook + The DocBook + Open Repository contains DSSSL stylesheets and + other resources for people using DocBook @@ -114,8 +117,8 @@ - The Linux Documentation - Project web pages + The Linux + Documentation Project web pages ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml#7 (text+ko) ==== @@ -27,70 +27,73 @@ ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - $FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml,v 1.80 2010/08/08 13:54:36 jkois Exp $ + $FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml,v 1.81 2012/04/21 04:52:03 wblock Exp $ --> SGML Markup - This chapter describes the two markup languages you will encounter - when you contribute to the FreeBSD documentation project. Each section - describes the markup language, and details the markup that you are likely - to want to use, or that is already in use. + This chapter describes the two markup languages you will + encounter when you contribute to the FreeBSD documentation + project. Each section describes the markup language, and details + the markup that you are likely to want to use, or that is already + in use. + + These markup languages contain a large number of elements, and + it can be confusing sometimes to know which element to use for a + particular situation. This section goes through the elements you + are most likely to need, and gives examples of how you would use + them. - These markup languages contain a large number of elements, and it can - be confusing sometimes to know which element to use for a particular - situation. This section goes through the elements you are most likely to - need, and gives examples of how you would use them. - - This is not an exhaustive list of elements, since - that would just reiterate the documentation for each language. The aim of - this section is to list those elements more likely to be useful to you. - If you have a question about how best to markup a particular piece of - content, please post it to the &a.doc;. + This is not an exhaustive list of + elements, since that would just reiterate the documentation for + each language. The aim of this section is to list those elements + more likely to be useful to you. If you have a question about how + best to markup a particular piece of content, please post it to + the &a.doc;. Inline vs. Block - + In the remainder of this document, when describing elements, - inline means that the element can occur within a - block element, and does not cause a line break. A - block element, by comparison, will cause a line - break (and other processing) when it is encountered. + inline means that the element can occur + within a block element, and does not cause a line break. A + block element, by comparison, will cause a + line break (and other processing) when it is encountered. - + HTML - - HTML, the HyperText Markup Language, is the markup language of - choice on the World Wide Web. More information can be found at - . + + HTML, the HyperText Markup Language, is the markup language + of choice on the World Wide Web. More information can be found + at . + + HTML is used to markup pages on the FreeBSD web site. It + should not (generally) be used to mark up other documentation, + since DocBook offers a far richer set of elements to choose + from. Consequently, you will normally only encounter HTML pages + if you are writing for the web site. - HTML is used to markup pages on the FreeBSD web site. It should not - (generally) be used to mark up other documentation, - since DocBook offers a - far richer set of elements to choose from. Consequently, you will - normally only encounter HTML pages if you are writing for the web - site. + HTML has gone through a number of versions, 1, 2, 3.0, 3.2, + and the latest, 4.0 (available in both + strict and loose + variants). - HTML has gone through a number of versions, 1, 2, 3.0, 3.2, and the - latest, 4.0 (available in both strict and - loose variants). - - The HTML DTDs are available from the Ports Collection in the - textproc/html port. They are automatically - installed as part of the textproc/docproj - port. + The HTML DTDs are available from the Ports Collection + in the textproc/html port. + They are automatically installed as part of the textproc/docproj port. Formal Public Identifier (FPI) - There are a number of HTML FPIs, depending upon the version (also - known as the level) of HTML that you want to declare your document to - be compliant with. + There are a number of HTML FPIs, depending upon the + version (also known as the level) of HTML that you want to + declare your document to be compliant with. - The majority of HTML documents on the FreeBSD web site comply with - the loose version of HTML 4.0. + The majority of HTML documents on the FreeBSD web site + comply with the loose version of HTML 4.0. PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" @@ -98,16 +101,17 @@ Sectional Elements - An HTML document is normally split into two sections. The first - section, called the head, contains - meta-information about the document, such as its title, the name of - the author, the parent document, and so on. The second section, the - body, contains the content that will be displayed - to the user. + An HTML document is normally split into two sections. The + first section, called the head, contains + meta-information about the document, such as its title, the + name of the author, the parent document, and so on. The + second section, the body, contains the + content that will be displayed to the user. - These sections are indicated with head and - body elements respectively. These elements are - contained within the top-level html element. + These sections are indicated with head + and body elements respectively. These + elements are contained within the top-level + html element. Normal HTML Document Structure @@ -125,24 +129,25 @@ </html> - + Block Elements Headings - HTML allows you to denote headings in your document, at up to - six different levels. + HTML allows you to denote headings in your document, at + up to six different levels. - The largest and most prominent heading is h1, - then h2, continuing down to - h6. + The largest and most prominent heading is + h1, then h2, + continuing down to h6. The element's content is the text of the heading. - <sgmltag>h1</sgmltag>, <sgmltag>h2</sgmltag>, etc. + <sgmltag>h1</sgmltag>, <sgmltag>h2</sgmltag>, + etc. Use: @@ -160,20 +165,22 @@

This is the heading for the second section

-]]> +]]> - - Generally, an HTML page should have one first level heading - (h1). This can contain many second level - headings (h2), which can in turn contain many - third level headings. Each - hn element should have - the same element, but one further up the hierarchy, preceding it. - Leaving gaps in the numbering is to be avoided. + + Generally, an HTML page should have one first level + heading (h1). This can contain many + second level headings (h2), which can in + turn contain many third level headings. Each + hn element + should have the same element, but one further up the + hierarchy, preceding it. Leaving gaps in the numbering is + to be avoided. Bad Ordering of - <sgmltag>h<replaceable>n</replaceable></sgmltag> Elements + hn + Elements Use: @@ -186,7 +193,7 @@ ]]> - + Paragraphs @@ -206,8 +213,9 @@ Block Quotations - A block quotation is an extended quotation from another document - that should not appear within the current paragraph. + A block quotation is an extended quotation from another + document that should not appear within the current + paragraph. <sgmltag>blockquote</sgmltag> @@ -228,32 +236,35 @@ Lists - You can present the user with three types of lists, ordered, - unordered, and definition. + You can present the user with three types of lists, + ordered, unordered, and definition. - Typically, each entry in an ordered list will be numbered, while - each entry in an unordered list will be preceded by a bullet point. - Definition lists are composed of two sections for each entry. The - first section is the term being defined, and the second section is - the definition of the term. + Typically, each entry in an ordered list will be + numbered, while each entry in an unordered list will be + preceded by a bullet point. Definition lists are composed + of two sections for each entry. The first section is the + term being defined, and the second section is the definition + of the term. Ordered lists are indicated by the ol - element, unordered lists by the ul element, and - definition lists by the dl element. + element, unordered lists by the ul + element, and definition lists by the dl + element. - Ordered and unordered lists contain listitems, indicated by the - li element. A listitem can contain textual - content, or it may be further wrapped in one or more - p elements. + Ordered and unordered lists contain listitems, indicated + by the li element. A listitem can + contain textual content, or it may be further wrapped in one + or more p elements. Definition lists contain definition terms (dt) and definition descriptions - (dd). A definition term can only contain inline - elements. A definition description can contain other block - elements. + (dd). A definition term can only contain + inline elements. A definition description can contain other + block elements. - <sgmltag>ul</sgmltag> and <sgmltag>ol</sgmltag> + <sgmltag>ul</sgmltag> and + <sgmltag>ol</sgmltag> Use: @@ -310,10 +321,11 @@ Pre-formatted Text - You can indicate that text should be shown to the user exactly - as it is in the file. Typically, this means that the text is shown - in a fixed font, multiple spaces are not merged into one, and line - breaks in the text are significant. + You can indicate that text should be shown to the user + exactly as it is in the file. Typically, this means that + the text is shown in a fixed font, multiple spaces are not + merged into one, and line breaks in the text are + significant. In order to do this, wrap the content in the pre element. @@ -321,8 +333,8 @@ <sgmltag>pre</sgmltag> - You could use pre to mark up an email - message: + You could use pre to mark up an + email message: From: nik@FreeBSD.org To: freebsd-doc@FreeBSD.org @@ -343,10 +355,10 @@ shown had to use &lt; instead of <. For consistency, &gt; was used in place of - >, too. Watch out for the special characters - that may appear in text copied from a plain-text source, - e.g., an email message or program code. - + >, too. Watch out for the special + characters that may appear in text copied from a + plain-text source, e.g., an email message or program + code. @@ -354,18 +366,19 @@ Tables - Most text-mode browsers (such as Lynx) do not render tables - particularly effectively. If you are relying on the tabular - display of your content, you should consider using alternative - markup to prevent confusion. + Most text-mode browsers (such as Lynx) do not render + tables particularly effectively. If you are relying on + the tabular display of your content, you should consider + using alternative markup to prevent confusion. - Mark up tabular information using the table - element. A table consists of one or more table rows - (tr), each containing one or more cells of table - data (td). Each cell can contain other block - elements, such as paragraphs or lists. It can also contain another - table (this nesting can repeat indefinitely). If the cell only + Mark up tabular information using the + table element. A table consists of one + or more table rows (tr), each containing + one or more cells of table data (td). + Each cell can contain other block elements, such as + paragraphs or lists. It can also contain another table + (this nesting can repeat indefinitely). If the cell only contains one paragraph then you do not need to include the p element. @@ -390,10 +403,11 @@ ]]> - A cell can span multiple rows and columns. To indicate this, - add the rowspan and/or colspan - attributes, with values indicating the number of rows or columns - that should be spanned. + A cell can span multiple rows and columns. To indicate + this, add the rowspan and/or + colspan attributes, with values + indicating the number of rows or columns that should be + spanned. Using <literal>rowspan</literal> @@ -481,14 +495,17 @@ You have two levels of emphasis available in HTML, em and strong. em is for a normal level of emphasis and - strong indicates stronger emphasis. + strong indicates stronger + emphasis. - Typically, em is rendered in italic and - strong is rendered in bold. This is not always - the case, however, and you should not rely on it. + Typically, em is rendered in italic + and strong is rendered in bold. This is + not always the case, however, and you should not rely on + it. - <sgmltag>em</sgmltag> and <sgmltag>strong</sgmltag> + <sgmltag>em</sgmltag> and + <sgmltag>strong</sgmltag> Use: @@ -500,9 +517,9 @@ Bold and Italics - Because HTML includes presentational markup, you can also - indicate that particular content should be rendered in bold or - italic. The elements are b and + Because HTML includes presentational markup, you can + also indicate that particular content should be rendered in + bold or italic. The elements are b and i respectively. @@ -516,8 +533,8 @@ Indicating Fixed-Pitch Text - If you have content that should be rendered in a fixed pitch - (typewriter) typeface, use tt (for + If you have content that should be rendered in a fixed + pitch (typewriter) typeface, use tt (for teletype). @@ -534,29 +551,35 @@ Content Size - You can indicate that content should be shown in a larger or - smaller font. There are three ways of doing this. + You can indicate that content should be shown in a + larger or smaller font. There are three ways of doing + this. - Use big and small - around the content you wish to change size. These tags can be - nested, so <big><big>This is much - bigger</big></big> is possible. + Use big and + small around the content you wish to + change size. These tags can be nested, so + <big><big>This is much + bigger</big></big> is + possible. >>> TRUNCATED FOR MAIL (1000 lines) <<<