**Before the**

**Federal Communications Commission**

**Washington, D.C. 20554**

In the Matter of )

)

)

Closed Captioning Requirements for ) ET Docket No. 99-254

Digital Television Receivers )

)

)

**NOTICE OF PROPOSED RULE MAKING**

**Adopted: July 14, 1999 Released: July 15, 1999**

Comment Date: \[75 days after publication in Federal Register\]

Reply Comment Date: \[105 days after publication in Federal Register\]

By the Commission:

**INTRODUCTION**

1\. By this action, we propose to amend Part 15 of our rules to adopt
technical standards for the display of closed captions on digital
television (DTV) receivers. We also propose to require the inclusion of
closed captioning decoder circuitry in DTV receivers. The proposals
contained herein will help ensure access to digital programming for
people with disabilities. We take this action to fulfill the
Commission\'s obligations contained in the Television Decoder Circuitry
Act of 1990 (TDCA).[^1]

**BACKGROUND**

2\. Closed captioning is an assistive technology that allows persons
with hearing disabilities to enjoy television programming. Through
captioning, the audio portion of programming is displayed as text
superimposed over the video. Closed captioning information is encoded
and transmitted along with the video signal of television broadcasts.
The text is not ordinarily visible. In order to display closed
captioning, viewers must use either a set-top decoder or a television
receiver with integrated decoder circuitry.

3\. In 1990, Congress passed the TDCA. The Act was intended to reduce
the cost to consumers of receiving closed captioning, to make closed
captioning more widely available, and to create market incentives for
broadcasters to invest in and provide more captioned programming. The
Act requires that television receivers with picture screens 33 cm (13
inches) or larger contain built-in decoder circuitry designed to display
closed captioned television transmissions. The Act also requires that
the Commission take appropriate action to ensure that closed captioning
services continue to be available to consumers as new video technology
is developed.[^2] In 1991, the Commission amended Title 47 of the Code
of Federal Regulations by adding Section 15.119 to implement provisions
of the TDCA.[^3] Section 15.119 provides standards for the display of
closed captioned text on television receivers. The rules were intended
to apply to analog television receivers, the only receivers in use at
that time. The introduction of digital broadcasting now requires the
Commission to update its rules to fulfill its continuing obligations
under the TDCA.

4\. As part of the Telecommunications Act of 1996, Congress directed the
Commission to adopt rules that generally require video programming to be
closed captioned to ensure that it is accessible to persons with hearing
disabilities.[^4] In 1997, the Commission adopted rules to phase-in the
closed captioning of video programming including separate transition
schedules for \"new programming\" (i.e., programming first published or
exhibited on or after January 1, 1998) and \"pre-rule programming\"
(i.e., programming first published or exhibited before January 1,
1998).[^5] The rules require an increasing amount of captioned new
programming over an eight-year transition period with 100% of all new
nonexempt programming required to be captioned effective January 1,
2006.[^6] For pre-rule programming, we adopted a ten-year transition
period and require that 75% of pre-rule nonexempt programming be
captioned as of January 1, 2008.[^7] In addition, we defined as
\"pre-rule programming\" digital programming prepared or formatted for
reception on digital television receivers prior to the date on which
such television receivers must be equipped with decoder circuitry for
the display of digital closed captioning transmissions.[^8] This
narrowly defined class of digital programming will be subject to the
captioning requirements in accordance with the pre-rule transition
schedule.[^9] Once the standards adopted in the instant proceeding are
effective, programming prepared or formatted for display on television
receivers equipped for display of digital transmissions will fall under
the established definition of \"new programming\" and be subject to the
transition schedule for the captioning of new programming.

**DISCUSSION**

5\. In 1996, the Commission incorporated an industry approved
transmission standard for digital television broadcasts into its
rules.[^10] Although the standard included a data stream reserved for
closed captioning information, specific instructions for implementing
closed captioning services for digital television did not exist. Since
then, the Electronics Industries Alliance (EIA) has adopted EIA-708-A, a
standard which provides guidelines for caption providers as well as
encoder and decoder manufacturers to implement closed captioning
services with digital television technology.[^11] Accordingly, digital
television manufacturers now have an industry approved standard to use
for guidance in designing captioning-capable receivers. This *Notice*
proposes to incorporate the relevant sections of EIA-708-A into the
Commission\'s rules.

6\. EIA-708-A provides comprehensive instructions for the encoding,
delivery, and display of closed caption information for digital
television systems. The standard provides for a larger set of captioning
characters than the existing caption standard. It also supports user
options which enable caption display to be customized for a particular
viewer. For example, closed caption decoders functioning pursuant to
EIA-708-A may permit viewers to change various attributes of caption
text such as its font, spacing, color, or screen position. This will
allow viewers to change the size and appearance of captions to suit
their needs. Also, using EIA-708-A, caption providers may distribute the
caption text for a particular program at different reading levels.
Viewers would then have the option of displaying the standard
near-verbatim captions or alternate \"easy-reader\" captions written for
younger viewers or beginner readers. Captions for that same program may
also be distributed in alternate languages, simultaneously. We believe
that, because of these attributes, EIA-708-A provides substantial
benefits for consumers, and substantial improvements over current
captioning standards.

7\. This *Notice* proposes to incorporate Section 9 of EIA-708-A into
the Commission\'s rules.[^12] Section 9 contains recommendations for the
operation of DTV decoders with respect to closed captioning. These
recommendations were intended to provide minimum performance standards
for DTV caption decoders. Because Section 9 supplies manufacturers with
a set of common basic functions for DTV caption decoders, we believe
that it provides sufficient guidance for the successful implementation
of closed caption services with digital television receivers.[^13]
Accordingly, we propose to transcribe the recommendations contained in
Section 9 into requirements that will be contained in Part 15 of the
Commission\'s rules. DTV receivers will be required to function pursuant
to the recommendations contained therein. We seek comment on this
proposal.

8\. The recommendations contained in Section 9, however, do not exploit
the full range of capabilities provided elsewhere in EIA-708-A. For
example, Section 9.20 states that caption decoders may choose to support
display of only 8 or 22 foreground and background colors, as opposed to
the 64 colors possible with the full implementation of EIA-708-A. We
wish to emphasize therefore that, although we only propose to adopt the
recommendations contained in Section 9, nothing in this proposal would
prohibit the full implementation of capabilities defined throughout the
standard. Indeed, Section 9 of EIA-708-A notes that the minimum
recommendations are not intended to, and should not, restrict caption
providers from using the extensive capabilities available under the
standard. Nonetheless, we seek comment on whether there are more caption
features contained in EIA-708-A, in addition to those contained in
Section 9, that should be required for DTV receivers. Finally, whether
we adopt only Section 9 or additional requirements, we seek comment on
whether it is necessary to incorporate into our rules by reference the
entire EIA-708-A standard.

9\. [Receiver requirements]{.underline}. The TDCA requires closed
caption decoder circuitry to be included in all television receivers
with picture screens 13 inches or greater in size. For retail purposes,
television screen size is currently measured in accordance with Federal
Trade Commission (FTC) regulations.[^14] We propose to apply the FTC
labeling standard to DTV receivers. Accordingly, we propose to require
all DTV receivers with picture screens 13 inches or larger, measured in
accordance with the FTC regulations, to include closed caption decoder
circuitry that functions pursuant to the recommendations contained in
Section 9 of EIA-708-A. We invite comment on this proposal.

10\. We note that, because digital television picture screens will be
shaped differently than analog picture screens, based on the FTC
labeling requirements, similarly labeled DTV receivers and analog
receivers may actually have overall picture areas of different sizes.
Specifically, whereas current analog receivers have a screen size ratio
of 4:3, resulting in a relatively square picture screen, most digital
receivers will have a ratio of 16:9, resulting in a more rectangular
shape. Therefore, an analog receiver marketed with a picture screen
measuring "13 inches diagonal" will have a picture area of 81.12 sq.
inches. On the other hand, a DTV receiver labeled "13 inches diagonal"
will have a picture area of 72.18 sq. inches. We invite comment as to
whether the FTC screen size labeling standard is appropriate when
applied to DTV receivers in light of this definition issue.

11\. During the transition period from analog to digital broadcasting,
programming will be transmitted in both analog and digital formats.
Accordingly, the first few generations of DTV receivers are expected to
be designed to operate in a dual mode. Dual mode receivers will allow
consumers to enjoy the enhanced quality of digital broadcast stations
while retaining the ability to watch programming on existing analog
stations, all with the same receiver. For this type of receiver we
believe that it is important to ensure that closed captioning display
capability is available in both modes of operation. Accordingly, we
propose to require that dual mode receivers operating in the analog mode
provide closed captioning functionality pursuant to the Commission\'s
existing rules.[^15] In the digital mode, such receivers will be
required to function in accordance with EIA-708-A, as specified above.
We note that EIA-708-A supports transport of standard analog captioning
information. However, we propose to require that the decoder circuitry
in digital tuners respond primarily to any digitally formatted caption
information. In that way we can ensure that consumers who purchase DTV
receivers will be able to take advantage of the new capabilities of
captioning in the digital environment.[^16] We seek comment on this
proposal.

12\. We are aware that DTV reception capability will be marketed in a
number of ways. During the transition period we expect that many
consumers will purchase set-top DTV converter boxes that allow digitally
transmitted television signals to be displayed on analog receivers. We
also are aware that some manufacturers may choose to sell DTV tuners and
display units separately. Consumers will have the option of customizing
their DTV system in much the same way that is now done for computer
systems. We believe that most set-top converters and all separately sold
DTV tuners will be used with picture screens that are 13 inches or
larger. Therefore, we propose to require that all such devices be
subject to the provisions of the TDCA and provide for the display of
closed captioning. Specifically, we propose to require that DTV
converter boxes used with analog receivers either decode any analog
caption information that is transmitted with the DTV signal or pass this
information directly to the receiver in a form recognizable by the
receiver\'s built-in caption decoder. Separately sold DTV tuners will be
required to have the capability to respond to digitally encoded caption
information. Although these converter boxes and tuners may be marketed
without display screens, we tentatively conclude that 47 U.S.C. § 330(b)
provides the Commission with authority to require closed captioning
capability in the devices. We seek comment.

13\. [Cost]{.underline}. We seek comment on the estimated cost to
consumers associated with our proposal to require that dual mode
receivers be capable of displaying both analog and digitally formatted
captions. Similarly, we seek comment on the cost of including the
proposed closed captioning functionality in set-top DTV converter boxes
and separately sold DTV tuner. We do not believe that the requirements
proposed herein will significantly impact costs for such equipment.
However, we solicit comment on this matter.

14\. [Effective date]{.underline}. Finally, we propose that these rules
become effective one year after adoption. We clarify that the effective
date will indicate the time at which manufacturers must begin including
this functionality in its products. We note that in previous filings
with the Commission CEMA, a trade association representing manufacturers
of consumer electronic devices, has indicated that the design cycle for
television receivers generally lasts 18-24 months. According to CEMA,
the cycle typically begins in January and leads to product introduction
in the summer of the following year. Notwithstanding, we believe that a
one year transition is reasonable given that the deadline is in
reference to the date of manufacture, not the date of availability.
Further, we believe that a one year transition period will provide
sufficient time for programmers to incorporate closed captioning
consistent with these standards into the digital programming they
distribute. We seek comment on this issue.

15\. We are aware that the proposals contained in this Notice may
require hardware and software re-design shortly before or after January
1, 2000. Therefore, we also seek comment as to whether this
implementation schedule will have an adverse impact on any year 2000
remediation efforts already undertaken by manufacturers.

**PROCEDURAL MATTERS**

**A. Regulatory Flexibility Act**

16\. As required by Section 603 of the Regulatory Flexibility Act,
5 U.S.C. § 603, the Commission has prepared an Initial Regulatory
Flexibility Analysis (IRFA) of the expected impact on small entities of
the proposals suggested in this document. The IRFA is set forth in
Appendix A. Written public comments are requested on the IRFA. These
comments must be filed in accordance with the same filing deadlines as
comments on the rest of the *Notice*, but they must have a separate and
distinct heading designating them as responses to the IRFA. The
Commission shall send a copy of this *Notice*, including the IRFA, to
the Chief Counsel for Advocacy of the Small Business Administration in
accordance with Section 603(a) of the Regulatory Flexibility Act, 5
U.S.C. § 603(a).

**B. *Ex Parte* Rules \-- Permit-But-Disclose Proceedings**

17\. This is a permit-but-disclose notice and comment rule making
proceeding. *Ex parte* presentations are permitted, except during any
Sunshine Agenda period, provided they are disclosed as provided in the
Commission\'s rules. *See generally* 47 C.F.R. §§ 1.1200(a), 1.1203, and
1.1206.

**C. Authority**

18\. This action is taken pursuant to Sections 303(u) and 330(b) of the
Communications Act of 1934, as amended, 47 U.S.C. Sections 303(u) and
330(b).

**D. Comment Dates**

19\. Pursuant to Sections 1.415 and 1.419 of the Commission\'s rules, 47
C.F.R. §§ 1.415, 1.419, interested parties may file comments on before
**\[75 days after publication in the Federal Register\]**, and reply
comments on or before **\[105 days after publication in the Federal
Register\]**. Comments may be filed using the Commission\'s Electronic
Comment Filing System (ECFS) or by filing paper copies.
[See]{.underline} [Electronic Filing of Documents in Rulemaking
Proceedings]{.underline}, 63 Fed. Reg. 24,121 (1998).

20\. Comments filed through the ECFS can be sent as an electronic file
via the Internet at \<http://www.fcc.gov/e-file/ecfs.html\>. Generally,
only one copy of an electronic submission must be filed. If multiple
docket or rulemaking numbers appear in the caption of this proceeding,
however, commenters must transmit one electronic copy of the comments to
each docket or rulemaking number referenced in the caption. In
completing the transmittal screen, commenters should include their full
name, Postal Service mailing address, and the applicable docket or
rulemaking number. Parties may also submit an electronic comment by
Internet e-mail. To get filing instructions for e-mail comments,
commenters should send an e-mail to ecfs@fcc.gov, and should include the
following words in the body of the message, \"get form \<your e-mail
address\>.\" A sample form and directions will be sent in reply.

21\. Parties who choose to file by paper must file an original and four
copies of each filing. If more than one docket or rulemaking number
appear in the caption of this proceeding, commenters must submit two
additional copies for each additional docket or rulemaking number. All
filings must be sent to the Commission\'s Secretary, Magalie Roman
Salas, Office of the Secretary, Federal Communications Commission, The
Portals, 445 Twelfth Street, S.W., Room TW‑A325, Washington, D.C. 20554.

22\. Parties who choose to file by paper should also submit their
comments on diskette. These diskettes should be submitted to: Neal L.
McNeil, Office of Engineering and Technology, Federal Communications
Commission, The Portals, 445 Twelfth Street, S.W., Room 7-A133,
Washington, D.C. 20554. Such a submission should be on a 3.5 inch
diskette formatted in an IBM compatible format using WordPerfect 5.1 for
Windows or compatible software. The diskette should be accompanied by a
cover letter and should be submitted in \"read only\" mode. The diskette
should be clearly labelled with the commenter\'s name, proceeding
(including the lead docket number, in this case ET Docket No. 99-254,
type of pleading (comment or reply comment), date of submission, and the
name of the electronic file on the diskette. The label should also
include the following phrase \"Disk Copy - Not an Original.\" Each
diskette should contain only one party\'s pleadings, preferably in a
single electronic file. In addition, commenters must send diskette
copies to the Commission\'s copy contractor, International Transcription
Service, Inc., 1231 20th Street, N.W., Washington, D.C. 20037.

23\. Comments and reply comments will be available for public inspection
during regular business hours in the Reference Information Center (Room
CY-A257) of the Federal Communications Commission, The Portals, 445
Twelfth Street, S.W., Washington, D.C. 20554. Copies of comments and
reply comments are available through the Commission\'s duplicating
contractor: International Transcription Service, Inc. (ITS, Inc.), 1231
20th Street, N.W., Washington, D.C. 20036, (202) 857‑3800, TTY (202)
293‑8810.

24\. Alternative formats (computer diskette, large print, audio cassette
and Braille) are available to persons with disabilities by contacting
Martha Contee at (202) 418-0260, TTY (202) 418-2555, or at
mcontee@fcc.gov. The *Notice* can also be downloaded at:
http://www.fcc.gov/dtf/.

**ORDERING CLAUSES**

25\. IT IS ORDERED that, pursuant to Sections 303(u) and 330(b) of the
Communications Act of 1934, as amended, 47 U.S.C. Sections 303(u) and
330(b), this Notice of Proposed Rule Making is hereby ADOPTED.

26\. IT IS FURTHER ORDERED that the Commission\'s Office of Public
Affairs Reference Operations Division, SHALL SEND a copy of this Notice
of Proposed Rule Making, including the Initial Regulatory Flexibility
Act, to the Chief, Counsel for Advocacy of the Small Business
Administration.

27\. For further information concerning this *Notice*, contact Neal
McNeil, Office of Engineering & Technology, (202) 418-2408, TTY (202)
418-2989, email nmcneil@fcc.gov.

FEDERAL COMMUNICATIONS COMMISSION

Magalie Roman Salas

Secretary

**APPENDIX A**

**INITIAL REGULATORY FLEXIBILITY ANALYSIS**

As required by Section 603 of the Regulatory Flexibility Act,[^17] the
Commission has prepared an Initial Regulatory Flexibility Analysis
(IRFA) of the expected significant economic impact on small entities by
the policies and rules proposed in this *Notice of Proposed Rule Making
(Notice).* Written public comments are requested on the IRFA. Comments
must be identified as responses to the IRFA and must be filed by the
deadlines for comments on the *Notice* provided above. The Commission
shall send a copy of this *Notice*, including the IRFA, to the Chief
Counsel for Advocacy of the Small Business Administration in accordance
with paragraph 603(a) of the Regulatory Flexibility Act.

**A. Need for and Objectives of the Proposed Rule.**

In 1990, Congress passed the Television Decoder Circuitry Act
(TDCA).[^18] The TDCA requires that any apparatus designed to receive
television broadcast signals, manufactured or imported for use in the
United States, must have the capability of displaying closed captioned
information if its television screen is 33 centimeters (13 inches) or
larger. In 1991, the FCC incorporated the TDCA into its rules by
requiring that each broadcast receiver shipped in interstate commerce,
manufactured, assembled, or imported after July 1, 1993 be capable of
displaying closed captioned information if its television screen is 33
centimeters or larger.[^19]

This *Notice* proposes to amend Part 15 of our Rules to require that
digital television receivers be capable of displaying closed captioning
transmitted with television signals.

**B. Legal Basis.**

The proposed action is taken pursuant to Sections 303(u) and 330(b) of
the Communications Act of 1934, as amended, 47 U.S.C. Sections 303(u)
and 330(b).

**C. Description and Estimate of the Number of Small Entities to Which
the Proposed Rules Will Apply.**

The RFA generally defines the term \"small entity\" as having the same
meaning as the terms \"small business\" \"small organization,\" and
\"small governmental jurisdictions.\" In addition, the term \"small
business\" has the same meaning as the term \"small business concern\"
under the Small Business Act, 15 U.S.C. § 632, unless the Commission has
developed one or more definitions that are appropriate to its
activities.[^20] Under the Small Business Act, a \"small business
concern\" is one that: (1) is independently owned and operated; (2) is
not dominant in its field of operation; and (3) meets any additional
criteria established by the Small Business Administration (SBA).[^21]

According to the SBA\'s regulations, television equipment manufacturers
must have 750 or fewer employees in order to qualify as a small business
concern.[^22] Census Bureau data indicates that there are 858 U.S.
companies that manufacture radio and television broadcasting and
communications equipment, and that 778 of these firms have fewer than
750 employees and would be classified as small entities.[^23] The Census
Bureau category is very broad, and specific figures are not available as
to how many of these firms are manufacturers of television equipment.
However, we believe that many of the companies that manufacture
television equipment may qualify as small entities.

**D. Description of Projected Reporting, Recordkeeping and Other
Compliance Requirements.**

The Commission\'s rules require television receivers to be verified for
compliance with applicable FCC technical requirements. See 47 C.F.R.
Sections 15.101, 15.117, and 2.951, *et seq*. Documentation concerning
the verification must be kept by the manufacturer or importer. The rules
adopted in this proceeding require that digital television receivers
comply with industry-developed standards for closed captioning display.
However, testing regarding closed captioning display is not necessary
because compliance with the industry-developed standards, and the
associated Commission rules, can be determined easily during the
equipment design process. The Commission may, of course, ask
manufacturers and importers to document upon occasion how a particular
television receiver or computer system complies with the closed
captioning display requirements.

**E. Significant Alternatives to Proposed Rules Which Minimize
Significant Economic Impact on Small Entities and Accomplish Stated
Objectives.**

None.

**F. Federal Rules that May Duplicate, Overlap, or Conflict With the
Proposed Rule.**

None.

**APPENDIX B**

**EIA-708-A, Section 9**

**9 DTVCC Decoder Manufacturer Recommendations**

> The following are the recommendations for DTV Closed Captioning
> decoder implementation including DTV, SDTV and HDTV. These
> recommendations are directed to the least common denominator of all of
> the DTVCC features described in the previous sections. Although
> voluntary, these recommendations should be considered as requirements
> for a realistic minimal implementation of the DTVCC capabilities.
> These minimal recommendations provide a bridge from NTSC
> (ANSI/EIA-608) captioning implementation to the eventual full-feature
> implementation of this DTVCC specification .
>
> It should be emphasized that these minimum recommendations are not
> intended to, and should not, restrict caption providers from using the
> whole suite of DTVCC commands and their extensive capabilities. The
> following sections address the minimum recommendations that have been
> anticipated, but may not cover all conditions and manifestations. It
> is up to the manufacturer to consider all situations that are not
> explicitly presented herein.
>
> NOTE\--The section numbers in the following headings refer to the
> corresponding sections in the current
>
> DTVCC Specification, EIA-708-A, to which the minimum recommendations
> apply.
>
> **9.1 DTVCC Section 4.2 - Pre-Allocated Bandwidth**
>
> While the DTVCC Caption Channel provides a continuous 9600 bps bit
> stream within the DTVCC Transport Channel, the individual bandwidth
> allocated to any single service shall not exceed 25% of the total
> bandwidth averaged over any 1 second time interval. This limit permits
> a maximum, average captioning data rate of 300 Bpsper service.
>
> That is, decoders need only implement enough buffering and processing
> power to handle a maximum of 2400 bps for each service. In effect,
> when this limit is exceeded for a service, the input storage buffer
> allocated for the service will overflow and data not already buffered
> will be lost.
>
> NOTE\-- In contrast, the per-service limitation addressed above still
> provides a five-fold enhancement over the maximum possible NTSC
> Closed-Caption service data rate of 60 Bps.

**9.2 DTVCC Section 6.1 - Services**

> Decoders should be capable of decoding and processing data for at
> least one (1) service. Decoders shall be capable of decoding and
> processing the Caption Service Directory data*.*
>
> **9.3 DTVCC Section 6.2 - Caption Channel Service Blocks**
>
> Decoders should be capable of decoding all Caption Channel Block
> Headers consisting of Standard Service Headers, Extended Service Block
> Headers, and Null Block headers. However, decoding of the data is
> required only for Standard Service Blocks (Service IDs \<= 6), and
> then only if the characters for the corresponding language are
> supported.
>
> Decoders should be able to display the directory for services 1
> through 6. Service decoding and directory display for services
> numbered 7 or greater are optional.

**9.4 DTVCC Section 7.1 - Code Space Organization**

Decoders must support Code Space C0, G0, C1, and G1 in their entirety.

> The following characters within code space G2 must be supported:
>
> transparent space (TSP)
>
> non-breaking transparent space (NBTSP)
>
> solid block (█)
>
> trademark symbol ()
>
> Latin-1 characters (Š, Œ, š, œ, Ÿ)

The substitutions in Table 17 are to be made if a decoder does not
support the remaining G2 characters.

  ----------------------------------- -----------------------------------
  **G2 Character**                    **Substitute With**

  open single quote (**'**), G2 char  G0 single quote ('), char code 0x27
  code 0x31                           

  close single quote(**'**), G2 char  G0 single quote ('), char code 0x27
  code 0x32                           

  open double quote (**"**), G2 char  G0 double quote ("), char code 0x22
  code 0x33                           

  close double quote (**"**), G2 char G0 double quote ("), char code 0x22
  code 0x34                           

  bold bullet (•), G2 char code 0x35  G1 bullet (·), char code 0xB7

  ellipsis(), G2 char code 0x25       G0 underscore (\_), char code 0x5F

  one-eighth ( **1 /8**), G2 char     G0 percent sign (%), char code 0x25
  code 0x76                           

  three-eighths ( **3 /8**), G2 char  G0 percent sign (%), char code 0x25
  code 0x77                           

  five-eighths ( **5 /8**), G2 char   G0 percent sign (%), char code 0x25
  code 0x78                           

  seven-eighths ( **7 /8**), G2 char  G0 percent sign (%), char code 0x25
  code 0x79                           

  vertical border (│), G2 char code   G0 stroke (\|), char code 0x7C
  0x7A                                

  upper-right border (┐), G2 char     G0 dash (-), char code 0x2D
  code 0x7B                           

  lower-left border (└ ), G2 char     G0 dash (-), char code 0x2D
  code 0x7C                           

  horizontal border (─ ),G2 char code G0 dash (-), char code 0x2D
  0x7D                                

  lower-right border (┘), G2 char     G0 dash (-), char code 0x2D
  code 0x7E                           

  upper-left border (┌ ), G2 char     G0 dash (-), char code 0x2D
  code 0x7F                           
  ----------------------------------- -----------------------------------

**Table 17 G2 Character Substitution Table**

Support for code spaces C2, C3, and G3 is optional.

> All unsupported graphic symbols in the G3 code space are to be
> substituted with the G0 underscore character (\_), char code 0x5F.
>
> **9.5 DTVCC Section 8.2 - Screen Coordinates**
>
> Table 18 specifies the minimum screen coordinate recommendations for
> anchor point positioning in 4:3 and 16:9 display formats, and the
> number of characters per row.
>
> **Screen Aspect Ratio Maximum Anchor Minimum Anchor**
>
> **Position Resolution Position Resolution**
>
> 4:3 75v x 160h 15v x 32h
>
> 16:9 75v x 210h 15v x 42h
>
> other 75v x (5 x H) 15v x H\*

[Table 18 Minimum Screen Coordinates]{.underline}

> \*H = 32 x (the width of the screen in relation to a 4:3 display). For
> example, the 16:9 format is 4/3 wider than a 4:3 display; thus, H = 32
> \* 4/3 = 42.667, or 42.
>
> This means that the minimum grid resolution for a 4:3 aspect ratio
> instrument is 15 vertical positions x 32 horizontal positions. This
> minimum grid resolution for 16:9 ratio instrument is 15 vertical
> positions x 42 horizontal positions. These minimum grid sizes are to
> cover the entire safe-title area of the corresponding screen.
>
> The minimum coordinates equate to a 1/5 reduction in the maximum
> horizontal and vertical grid resolution coordinates. Caption providers
> are to use the maximum coordinate system values when specifying anchor
> point positions. Decoders using the minimum resolution are to divide
> the provided horizontal and vertical screen coordinates by 5 to derive
> the equivalent minimum coordinates.
>
> Any caption targeted for both 4:3 and 16:9 instruments is limited to
> 32 contiguous characters per row. If a caption is received by a 4:3
> instrument that is targeted for a 16:9 display only, or requires a
> window width greater than 32 characters, then the caption may be
> completely disregarded by the decoder. 16:9 instruments should be able
> to process and display captions intended for 4:3 displays, providing
> all other minimum recommendations are met.
>
> If the resulting size of any window is larger than the safe title area
> for the corresponding display's aspect ratio, then this window will be
> completely disregarded.

**9.6 DTVCC Section 8.4 - Caption Windows**

> Decoders need to display no more than 4 rows of captions on the screen
> at any given time, regardless of the number of windows displayed. This
> implies that no more than 4 windows can be displayed at any given time
> (with each having only one caption row).
>
> However, decoders should maintain storage to support a maximum total
> of 8 rows of captions. This storage is needed for the worst-case
> support of a displayed window with 4 rows of captioning and a
> non-displayed window which is buffering the incoming rows for the next
> 4-row caption.
>
> As implied above, the maximum number of windows that may be displayed
> at any one time by a minimum decoder implementation is 4. If more than
> 4 windows are defined in the caption stream, the decoder may disregard
> the youngest and lowest priority window definition(s). Caption
> providers must be aware of this limitation, and either restrict the
> total number of windows used or accept that some windows will not be
> displayed.
>
> **9.7 DTVCC Section 8.4.2 - Window Priority**
>
> Decoders do not need to support overlapped windows. If a window
> overlaps another window, the overlapped window need not be displayed
> by the decoder. Decoders may support overlapped windows as an option.

**9.8 DTVCC Section 8.4.6 - Window Size**

> At a minimum, decoders will assume that all windows have rows and
> columns "locked". This implies that if a decoder implements the
> optional SMALL pen-size, then word-"un"wrapping, when shrinking
> captions, need not be implemented. Also, if a decoder implements the
> optional LARGE pen size, then word wrapping (when enlarging captions)
> need not be implemented.

**9.9 DTVCC Section 8.4.8 - Word Wrapping**

Decoders may support word wrapping as an option.

**9.10 DTVCC Section 8.4.9 - Window Text Painting**

**9.10.1 Justification**

> For fixed-spaced (i.e., non-proportionally-spaced) fonts, all decoders
> should implement "left", "right", and "center"caption-text
> justification, with "full" justification implementation being
> optional. "Full" justification is to be converted to "left"
> justification when "full" justification is not implemented
>
> For proportionally-spaced fonts, all decoders should implement left,
> right and center justification. For center and right justification,
> decoders need not display any portion of a received row of text until
> the entire row is received (i.e., until a CR or any non-text related
> command is received). This easement allows the decoder to calculate
> the "width" of a text row before displaying it, and thus, giving the
> decoder all of the parameters necessary to calculate a reasonable
> offset of the row within a window to effect center or right
> justification.
>
> Receipt of a character for a displayed row which already contains text
> and which has already been "justified" will cause the row to be
> cleared prior to the display of the newly received character and any
> subsequent characters. Receipt of a justification command which
> changes the last received justification for a given window will cause
> the window to be cleared.

**9.10.2 Print Direction**

At a minimum, decoders must support LEFT_TO_RIGHT printing.

**9.10.3 Scroll Direction**

At a minimum, decoders must support BOTTOM_TO_TOP scrolling.

For windows sharing the same horizontal scan lines on the display,
scrolling may be disabled.

**9.10.4 Scroll Rate**

> At a minimum, decoders must support the same recommended practices for
> scroll rate as is provided for NTSC closed-captioning.

**9.10.5 Smooth Scrolling**

> At a minimum, decoders must support the same recommended practices for
> smooth scrolling as is provided for NTSC closed-captioning.

**9.10.6 Display Effects**

> At a minimum, decoders must implement the "snap" window display
> effect. If the window "fade" and "wipe" effects are not implemented,
> then the decoder will "snap" all windows when they are to be
> displayed, and the

**9.11 DTVCC Section 8.4.11 - Window Colors and Borders**

> At a minimum, decoders need only to implement borderless windows with
> solid, black backgrounds (i.e., border type = NONE, fill color =
> (0,0,0), fill opacity = SOLID), and borderless transparent windows
> (i.e., border type = NONE, fill opacity = TRANSPARENT).

**9.12 DTVCC Section 8.4.12 - Predefined Window and Pen Styles**

> Predefined Window Style and Pen Style ID's may be provided in the
> DefineWindow command. At a minimum, decoders should implement
> Predefined Window Attribute Style 1 and Predefined Pen Attribute Style
> 1, as shown in Table 19 and Table 20.

<table style="width:100%;">
<colgroup>
<col style="width: 6%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 6%" />
<col style="width: 6%" />
<col style="width: 8%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 6%" />
<col style="width: 6%" />
<col style="width: 14%" />
</colgroup>
<tbody>
<tr class="odd">
<td>Style ID #</td>
<td>Justify</td>
<td>Print Direction</td>
<td>Scroll Direction</td>
<td>Word Wrap</td>
<td>Display Effect</td>
<td>Effect Direction</td>
<td>Effect Speed</td>
<td>Fill Color</td>
<td>Fill Opacity</td>
<td>Border Type</td>
<td>Border Color</td>
<td>Usage</td>
</tr>
<tr class="even">
<td>1</td>
<td>LEFT</td>
<td><p>LEFT</p>
<p>-TO-</p>
<p>RIGHT</p></td>
<td><p>BOTTOM</p>
<p>-TO-</p>
<p>TOP</p></td>
<td>NO</td>
<td>SNAP</td>
<td>n/a</td>
<td>n/a</td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>SOLID</td>
<td>NONE</td>
<td>n/a</td>
<td>NTSC Style PopUp Captions</td>
</tr>
<tr class="odd">
<td>2</td>
<td>LEFT</td>
<td><p>LEFT</p>
<p>-TO-</p>
<p>RIGHT</p></td>
<td><p>BOTTOM</p>
<p>-TO-</p>
<p>TOP</p></td>
<td>NO</td>
<td>SNAP</td>
<td>n/a</td>
<td>n/a</td>
<td>n/a</td>
<td><p>TRANS-</p>
<p>PARENT</p></td>
<td>NONE</td>
<td>n/a</td>
<td>PopUp Captions w/o Black Background</td>
</tr>
<tr class="even">
<td>3</td>
<td>CNTR</td>
<td><p>LEFT</p>
<p>-TO-</p>
<p>RIGHT</p></td>
<td><p>BOTTOM</p>
<p>-TO-</p>
<p>TOP</p></td>
<td>NO</td>
<td>SNAP</td>
<td>n/a</td>
<td>n/a</td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>SOLID</td>
<td>NONE</td>
<td>n/a</td>
<td>NTSC Style Centered PopUp Captions</td>
</tr>
<tr class="odd">
<td>4</td>
<td>LEFT</td>
<td><p>LEFT</p>
<p>-TO-</p>
<p>RIGHT</p></td>
<td><p>BOTTOM</p>
<p>-TO-</p>
<p>TOP</p></td>
<td>YES</td>
<td>SNAP</td>
<td>n/a</td>
<td>n/a</td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>SOLID</td>
<td>NONE</td>
<td>n/a</td>
<td>NTSC Stlye RollUp Captions</td>
</tr>
<tr class="even">
<td>5</td>
<td>LEFT</td>
<td><p>LEFT</p>
<p>-TO-</p>
<p>RIGHT</p></td>
<td><p>BOTTOM</p>
<p>-TO-</p>
<p>TOP</p></td>
<td>YES</td>
<td>SNAP</td>
<td>n/a</td>
<td>n/a</td>
<td>n/a</td>
<td><p>TRANS-</p>
<p>PARENT</p></td>
<td>NONE</td>
<td>n/a</td>
<td>RollUp Captions w/o Black Background</td>
</tr>
<tr class="odd">
<td>6</td>
<td>CNTR</td>
<td><p>LEFT</p>
<p>-TO-</p>
<p>RIGHT</p></td>
<td><p>BOTTOM</p>
<p>-TO-</p>
<p>TOP</p></td>
<td>YES</td>
<td>SNAP</td>
<td>n/a</td>
<td>n/a</td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>SOLID</td>
<td>NONE</td>
<td>n/a</td>
<td>NTSC Stlye Centered RollUp Captions</td>
</tr>
<tr class="even">
<td>7</td>
<td>LEFT</td>
<td><p>TOP</p>
<p>-TO-</p>
<p>BOTTOM</p></td>
<td><p>RIGHT</p>
<p>-TO-</p>
<p>LEFT</p></td>
<td>NO</td>
<td>SNAP</td>
<td>n/a</td>
<td>n/a</td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>SOLID</td>
<td>NONE</td>
<td>n/a</td>
<td>Ticker Tape</td>
</tr>
</tbody>
</table>

**Table 19 - Predefined Window Style ID\'s**

<table>
<colgroup>
<col style="width: 6%" />
<col style="width: 7%" />
<col style="width: 5%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 6%" />
<col style="width: 14%" />
</colgroup>
<tbody>
<tr class="odd">
<td>Pre-defined Style ID #</td>
<td>Pen Size</td>
<td>Font Style</td>
<td>Offset</td>
<td>Italics</td>
<td>Underline</td>
<td>Edge Type</td>
<td>Foregrnd Color</td>
<td>Foregrnd Opacity</td>
<td>Backgrnd Color</td>
<td>Backgrnd Opacity</td>
<td>Edge Color</td>
<td>Usage</td>
</tr>
<tr class="even">
<td>1</td>
<td>STNDR</td>
<td>0</td>
<td>NORMAL</td>
<td>NO</td>
<td>NO</td>
<td>NONE</td>
<td><p>(2,2,2)</p>
<p>White</p></td>
<td>SOLID</td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>SOLID</td>
<td>n/a</td>
<td>Default NTSC Style*</td>
</tr>
<tr class="odd">
<td>2</td>
<td>STNDR</td>
<td>1</td>
<td>NORMAL</td>
<td>NO</td>
<td>NO</td>
<td>NONE</td>
<td><p>(2,2,2)</p>
<p>White</p></td>
<td>SOLID</td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>SOLID</td>
<td>n/a</td>
<td>NTSC Style* Mono w/Serif</td>
</tr>
<tr class="even">
<td>3</td>
<td>STNDR</td>
<td>2</td>
<td>NORMAL</td>
<td>NO</td>
<td>NO</td>
<td>NONE</td>
<td><p>(2,2,2)</p>
<p>White</p></td>
<td>SOLID</td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>SOLID</td>
<td>n/a</td>
<td>NTSC Style* Prop w/Serif</td>
</tr>
<tr class="odd">
<td>4</td>
<td>STNDR</td>
<td>3</td>
<td>NORMAL</td>
<td>NO</td>
<td>NO</td>
<td>NONE</td>
<td><p>(2,2,2)</p>
<p>White</p></td>
<td>SOLID</td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>SOLID</td>
<td>n/a</td>
<td>NTSC Stlye* Mono w/o Serif</td>
</tr>
<tr class="even">
<td>5</td>
<td>STNDR</td>
<td>4</td>
<td>NORMAL</td>
<td>NO</td>
<td>NO</td>
<td>NONE</td>
<td><p>(2,2,2)</p>
<p>White</p></td>
<td>SOLID</td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>SOLID</td>
<td>n/a</td>
<td>NTSC Style* Prop w/o Serif</td>
</tr>
<tr class="odd">
<td>6</td>
<td>STNDR</td>
<td>3</td>
<td>NORMAL</td>
<td>NO</td>
<td>NO</td>
<td>UNIFRM</td>
<td><p>(2,2,2)</p>
<p>White</p></td>
<td>SOLID</td>
<td>n/a</td>
<td><p>TRANS-</p>
<p>PARENT</p></td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>Mono w/o Serif, Bordered Text, No BG</td>
</tr>
<tr class="even">
<td>7</td>
<td>LEFT</td>
<td>4</td>
<td>NORMAL</td>
<td>NO</td>
<td>NO</td>
<td>UNIFRM</td>
<td><p>(2,2,2)</p>
<p>White</p></td>
<td>SOLID</td>
<td>n/a</td>
<td>TRANS-PARENT</td>
<td><p>(0,0,0)</p>
<p>Black</p></td>
<td>Prop. w/o Serif, Bordered Text, No BG</td>
</tr>
</tbody>
</table>

**Table 20 - Predefined Pen Style ID\'s**

\* NTSC Stlye - White Text on Black Background

**9.13 DTVCC Section 8.5.1 - Pen Size**

At a minimum, decoders must support the STANDARD pen size, with the
implementation of the LARGE and SMALL pen sizes being optional.

The STANDARD pen size should be implemented such that the height of the
tallest character in any implemented font is no taller than 1/15 of the
height of the safe-title area, and the width of the widest character is
no wider than 1/32 of the width of the safe-title area for 4:3 displays
and 1/42 of the safe-title area width for 16:9 displays.

The LARGE pen size should be implemented such that the width of the
widest character in any implemented font is no wider than 1/32 of the
safe-title area for 16:9 displays. This recommendation allows for
captions to grow to a LARGE pen size without having to reformat the
caption since no caption will have more than 32 characters per row (see
Section 8.4.6).

**9.14 DTVCC Section 8.5.3 - Font Styles**

Although a caption service provider may specify any one of 8 font styles
using the **SetPenAttributes** command, decoders need only to implement
a single font for caption text display.

Decoders that implement more than one font but do not support a font
style specified in the **SetPenAttributes** command should instead
display the caption text in the most similar font available. In decoders
with only one font (i.e., font style 0, the default), all caption text,
regardless of the specified font style, will be displayed in the default
font.

In decoders with more than one but less than eight fonts, unsupported
font styles should be displayed using an alternate font, giving
precedence to the spacing attribute of the indicated font style, if
possible. For example, if the specified but unsupported font style is
"monospaced with serifs", the best substitute would be another
monospaced font, and the second-best alternative would be a
proportionally spaced font with serifs. If the Cursive font style is not
supported, an acceptable substitution is an italicized version of an
available font.

All supported font styles may be implemented in any typeface which the
decoder manufacturer deems to be a readable rendition of the font style,
and need not be in the exact typefaces given as examples in Section
8.5.3.

**9.15 DTVCC Section 8.5.4 - Character Offsetting**

Decoders need not to implement the character offsetting (i.e., subscript
and superscript) pen attributes.

**9.16 DTVCC Section 8.5.5 - Pen Styles**

At a minimum, decoders must implement normal, italic, and underline pen
styles.

**9.17 DTVCC Section 8.5.6 - Foreground Color and Opacity**

At a minimum, decoders must implement solid and flashing character
foreground type attributes.

At a minimum, decoders must implement the following character foreground
colors: white, black, red, green, blue, yellow, magenta and cyan.

**9.18 DTVCC Section 8.5.7 - Background Color and Opacity**

Decoders need only implement solid black character backgrounds. It is
recommended that this background is extended beyond the character
foreground to a degree that the foreground is separated from the
underlying video by a sufficient number of background pixels to insure
the foreground is separated from the background.

**9.19 DTVCC Section 8.5.8 - Character Edges**

Decoders need not to implement separate character edge color, opacity,
and type attribute control. In this case, there is no separately
controlled edge surrounding the body of characters.

**9.20 DTVCC Section 8.8 - Color Representation**

At a minimum, decoders must support the 8 colors described in Table 21.

**Color Red Green Blue**

Black 0 0 0

White 2 2 2

Red 2 0 0

Green 0 2 0

Blue 0 0 2

Yellow 2 2 0

Magenta 2 0 2

Cyan 0 2 2

###  

Table 21 Minimum Color List Table

When a decoder supporting this Minimum Color List receives an RGB value
not in the list, it will map the

received value to one of the values in the list via the following
algorithm:

All one (1) values are to be changed to 0

All two (2) values are to remain unchanged

All three (3) values are to be changed to 2

For example, the RGB value (1,2,3) will be mapped to (0,2,2), (3,3,3)
will be mapped to (2,2,2) and (1,1,1) will be mapped to (0,0,0).

Table 22 is an alternative minimum color list table supporting 22
colors.

  ----------------- ----------------- ----------------- -----------------
  **Color**         **Red**           **Green**         **Blue**

  Black             0                 0                 0

  Gray              1                 1                 1

  White             2                 2                 2

  Bright White      3                 3                 3

  Dark Red          1                 0                 0

  Red               2                 0                 0

  Bright Red        3                 0                 0

  Dark Green        0                 1                 0

  Green             0                 2                 0

  Bright Green      0                 3                 0

  Dark Blue         0                 0                 1

  Blue              0                 0                 2

  Bright Blue       0                 0                 3

  Dark Yellow       1                 1                 0

  Yellow            2                 2                 0

  Bright Yellow     3                 3                 0

  Dark Magenta      1                 0                 1

  Magenta           2                 0                 2

  Bright Magenta    3                 0                 3

  Dark Cyan         0                 1                 1

  Cyan              0                 2                 2

  Bright Cyan       0                 3                 3
  ----------------- ----------------- ----------------- -----------------

**Table 22 Alternative Minimum Color List Table**

When a decoder supporting the Alternative Minimum Color List in Table 22
receives an RGB value not in the list (i.e., an RGB value whose non-zero
elements are not the same value), it will map the received value to one
of the values in the list via the following algorithm:

For RGB values with all elements non-zero and different - e.g., (1,2,3),
(3,2,1), and (2,1,3), the 1

value will be changed to 0, the 2 value will remain unchanged, and the 3
value will be changed to 2.

For RGB values with all elements non-zero and with two common elements -
e.g. (3,1,3), (2,1,2), and

(2,2,3), if the common elements are 3 and the uncommon one is 1, then
the 1 elements is changed to

0; e.g. (3,1,3) -\> (3,0,3). If the common elements are 1 and the
uncommon element is 3, then the 1

elements are changed to 0, and the 3 element is changed to 2; e.g.
(1,3,1) -\> (0,2,0). In all other

cases, the uncommon element is changed to the common value; e.g.,
(2,2,3) -\> (2,2,2), (1,2,1) -\>

(1,1,1), and (3,2,3) -\> (3,3,3).

All decoders not supporting either one of the two color lists described
above, must support the full 64 possible RGB color value combinations*.*

**9.21 Character Rendition Considerations**

In NTSC Closed Captioning, decoders were required to insert leading and
trailing spaces on each caption row. There were two reasons for this
requirement:

1\. to provide a buffer so that the first and last characters of a
caption row do not fall outside the safe title area, and

2\. to provide a black border on each side of a character so that the
"white" leading pixels of the first

character on a row and the trailing "white" pixels of the last character
on a row do not bleed into the

underlying video.

Since caption windows are required to reside in the safe title area of
the DTV screen, reason number 1 (above) is not applicable to DTVCC
captions. The attributes available in the **SetPenAttributes** command
for character rendition (e.g.,character background and edge attributes)
provide unlimited flexibilty to the caption provider when describing
caption text in an ideal decoder implementation. However, manufacturers
need only implement a minimum of pen attributes and font styles. Thus it
is recommended that no matter what the level of implementation, decoder
manufacturers should take into account the readablility of all caption
text against a variety of all video backgrounds, and should implement
some automatic character delineation when the individual control of
character foreground, background and edge is not supported; and when
only a minimum number of font styles are implemented.

**9.22 DTVCC Section 8.9 - Service Synchronization**

Service Input Buffers must be at least 128 bytes in size. Caption
providers must keep this lower limit in mind when following Delay
commands with other commands and window text. In other words, no more
than 128 bytes of DTVCC commands and text should be transmitted
(encoded) before a pending Delay command's delay interval expires.

**9.23 DTV to NTSC Transcoders**

It is anticipated that receiver (decoder) manufacturers will develop
devices (e.g., settop boxes) which process an DTV stream and transcode
it for display on NTSC monitors. The DTVCC command set is not
necessarily transcodable to NTSC captions; i.e., there are DTVCC
captions which have no NTSC equivalent.

Although receiver manufacturers are free to attempt an automatic
transcode of the captions, there is no guarantee that the captions will
appear as the caption provider intended. Caption providers apply many
techniques to make the captions easy to read and as unobtrusive as
possible over the underlying video. To maintain caption quality during
an automated transcode process, a set of conversion rules would have to
be defined which cover all possible window, pen and text attribute
combinations.

Therefore, a separate NTSC caption channel was added to the Picture User
Data (see Section 4.3). This channel allows caption providers to encode
dual caption streams within the same programming. NTSC captions are
under the complete control of the caption provider; and thus, no
automated transcoding of captions is necessary.

[^1]: Pub. L. No. 101-431, 104 Stat. 960 (1990) (codified at 47 U.S.C.
    §§ 303(u), 330(b)).

[^2]: *See* 47 U.S.C. § 330(b).

[^3]: *See* 47 C.F.R. § 15.119, *Report and Order* in General Docket
    91-1, 6 FCC Rcd. 2419 (1991), 56 FR 27200 (1991).

[^4]: 47 U.S.C. § 613.

[^5]: *See Closed Captioning and Video Description of Video Programming,
    Implementation of Section 305 of the Telecommunications Act of 1996,
    Video Programming Accessibility*, MM Docket No. 95-176, Report and
    Order, 13 FCC Rcd 3272 (1998) (\"*Captioning Order*\"); *Closed
    Captioning and Video Description of Video Programming,
    Implementation of Section 305 of the Telecommunications Act of 1996,
    Video Programming Accessibility*, MM Docket No. 95-176, Order on
    Reconsideration, 13 FCC Rcd 19973 (1998) (\"*Captioning
    Reconsideration*\"). *See also* 47 C.F.R. § 79.1(a)(5)-(6).

[^6]: 47 C.F.R. § 79.1(b)(1), (3). As authorized by Congress, the rules
    exempt certain programming for which a closed captioning requirement
    would impose an economic burden. *See* 47 C.F.R. § 79.1(d).

[^7]: 47 C.F.R. § 79.1(b)(2), (4).

[^8]: *Captioning Order*, 13 FCC Rcd 3300-3301 ¶ 60; *Captioning
    Reconsideration*, 13 FCC Rcd 19986-19987 ¶ 27. Specifically,
    pursuant to 47 C.F.R. § 79.1, the definition of \"pre-rule
    programming\" includes:

    \[v\]ideo programming published or exhibited for display on
    television receivers equipped for display of digital transmissions
    or formatted for such transmission and exhibition prior to the date
    on which such television receivers must, by Commission rule, be
    equipped with built-in decoder circuitry designed to display
    closed-captioned digital television transmissions.

[^9]: *Captioning Reconsideration*, 13 FCC Rcd 19986-19987 ¶ 27.

[^10]: *See Fourth Report and Order* in MM Docket 87-268, 11 FCC Rcd.
    17771 (1996), 62 FR 14006 (1997).

[^11]: *See* EIA-708-A, Digital Television Closed Captioning, November
    23, 1998. A complete copy of this standard has been included in the
    docket of this proceeding. Copies of EIA-708-A may be obtained from:
    Global Engineering Documents, 15 Inverness Way East, Englewood, Co
    80112-5704, http://global.ihs.com/.

[^12]: EIA-708-A, Section 9 is included as Appendix B.

[^13]: We note that broadcasters are not obligated to provide the
    extensive features of EIA-708-A. However, Section 9 summarizes what
    EIA believes to be the essential elements of EIA-708-A necessary for
    effective DTV caption display.

[^14]: *See* 16 C.F.R. § 410, which reads in pertinent part:

    Note 1: For the purposes of this part, measurement of the picture
    area on a single plane basis refers to a measurement of the distance
    between the outer extremities (sides) of the picture area which does
    not take into account the curvature of the tube. . . .

    Examples of proper size descriptions when a television receiving set
    shows a 20‑inch picture measured diagonally, a 19‑inch picture
    measured horizontally, a 15‑inch picture measured vertically, and a
    picture area of 262 square inches include:

    \"20 inch (50.80 cm) picture measured diagonally\" or

    \"20 inch (50.80 cm) diagonal\"

    \"19 inch x 15 inch (48.26 cm x 38.10 cm) picture\" or

    \"19 inch (48.26 cm) picture\" or

    \"19 inch (48.26 cm)\" or

    \"262 square inch (1,690.32 cm. sq.) picture.\"

[^15]: *See* 47 C.F.R. § 15.119.

[^16]: We note that the PIAC Report also recommends that broadcasters
    take full advantage of digital closed captioning technologies to
    provide viewers with maximum choice and caption quality.

[^17]: 5 U.S.C. § 603.

[^18]: Pub. L. No. 101-431, 104 Stat. 960 (1990) (codified at 47 U.S.C.
    §§ 303(u), 330(b)).

[^19]: *See* 47 C.F.R. § 15.119, *Report and Order* in General Docket
    91-1, 6 FCC Rcd. 2419 (1991).

[^20]: [See]{.underline} 5 U.S.C. § 601(3).

[^21]: 15 U.S.C. § 632.

[^22]: 13 C.F.R. § 121.201, (SIC) Code 3663.

[^23]: U.S. Department of Commerce, [1992 Census of Transportation,
    Communications, and Utilities]{.underline}, SIC Code 3663 (issued
    may 1995).