- From: Leonard R. Kasday <kasday@acm.org>
- Date: Mon, 19 Jul 1999 17:08:38 -0400
- To: Anne Pemberton <apembert@crosslink.net>, "Waddell, Cynthia" <cynthia.waddell@ci.sj.ca.us>
- Cc: w3c-wai-ig@w3.org
Anne, re >Can you be more specific on how to >save the page in HTML to have the text boxes kept as text when the have >backgrounds or borders? The only thing I found to work with our newsletter is the brute force method... to create a new page without the features that you describe that cause the text to be converted to images. First, rearrange text and graphics so they don't overlap. This means that if you want a picture in the middle of a text block you have to split the block at that point into two blocks and put the picture between the blocks. As for borders and backgrounds. Publisher creates these, at least sometimes, by making an image consisting of the background and border, on which the text is overlaid. You have to delete that image. You still wind up with a page with <font> tags all over. The way we create our newsletter for print, the fonts turn out much too small for people with low vision... actually too small even for people with normal vision. So you have to delete the <font> tags. Like I said, you dont hit this problem if you change your web publishing option to File->web properties->site->HTML 4.0+ browsers However, then the order of the text blocks gets messed up, as I mentioned. You can work around this by having all your text as one block, perhaps continued to an overflow block. But that doesn't handle all formats, and doesn't handle legacy material that wasn't designed with that in mind. This is a LOT of work. I doubt if most people out there would want to go through the trouble. And like I say, it's not just a problem with Publisher. Oh yes, one more remark. All this applies to Publisher 98. It didn't happen with some docs we did with Publisher 97. However, it would be hard to go back, since Publisher 98 was part of a whole system upgrade and we don't want to risk messing with it. So I can't be sure what the difference was. Are you getting these problems with Publisher 97? Len At 10:51 AM 7/19/99 -0400, Anne Pemberton wrote: >Leonard, > > I frequently use Publisher to make web pages and have also run into the >problem of the program converting text boxes to graphics if they are given >a background color, border, or are physically touching/overlapping any >graphic files. It also converted a table to graphics, but I'm not sure of >the reason for that one. > > I usually save the pages as HTML, and when necessary, add/correct HTML >after Publisher puts it in HTML. So far, that has had no effect on whether >text is displayed as text or a graphic. Can you be more specific on how to >save the page in HTML to have the text boxes kept as text when the have >backgrounds or borders? > > Thanks, > > Anne > > > >At 10:44 AM 7/19/1999 -0400, Leonard R. Kasday wrote: >>Cynthia, >> >>Yes, Microsoft tried to help me create accessible version of Mi >>> >>>c >>Publisher docs, but unfortunately their initial solution >>>didn't >>>work >>adequately for out pages. They're still working on it. >>>Actually, >>>what >>we're hitting here is a basic problem of using editors >>>which allow >>>the user >>to drag elements around on the screen. >> >>Here's >>>the situation. >>> The original problem was that Publisher >>>would >>sometimes render text as >>>images. Microsoft suggested using the >>>option to >>save as a web page for >>>CSS-aware browsers. This fixed the >>>problem of >>rendering text as images. >>> >> >>But the text came out in the >>>wrong order. >> >>The problem is that >>>Publisher, like other graphical >>>editors, allows you to >>create a block of >>>text and then drag it >>>anywhere you want on the screen >>with the mouse. >>>When it creates a web >>>page, it uses style sheets to achieve >>that >>>position on the screen. >>>But the order that the text appears in the >>HTML >>>is something >>>different, (perhaps the order in which it was >>>created... >>this depends >>>on how they implemented the editor internally). So the reading >>order >>>comes out wrong. >> >>The WAI guidelines anticipated this in checkpoint >>>6.1, >> >>Quote >>Organize documents so they may be read without style >>>sheets...When content >>is organized logically, it will be rendered in a >>>meaningful order when >>style sheets are turned off or not supported. >>Unquote >> >>There's a basic difficulty here. For example, suppose a user position text >>blocks A, B, C, D like this: >> >>AB >>CD >> >>When the software renders the page there's no way for it to know whether to >>order it as >> >>ABCD >> >>or >> >>ACBD >> >>It's the same sort of problem Adobe Acrobat's HTML generator runs into when >>it's trying to figure out a logical order from a physical order. >> >>So what's really needed, when you have a Graphical Authoring Tools that >>lets the user independenly position elements, is a feature that allows the >>author to explicitly specify the order in which the elements should be >>read. (It would also be useful to have algorithms, like the ones in the >>Adobe converter, to make an intial guess.) >> >>By the way, even though I'm talking about this in the context of style >>sheets, it affects any program which allows the user to drag elements >>around. I get the same problem in Powerpoint for example. >> >>Len >> >> >> >> >> >>At 02:13 PM 7/16/99 -0700, Waddell, Cynthia wrote: >>>>>> >>>RE: How can we make Microsoft Publisher Accessible on the Web >>> >>>Lenoard- >>>Did you ever get a reply to this inquiry? >>>Cynthia >>> >>>--------------------------------------------------- >>>Cynthia D. Waddell >>>ADA Coordinator >>>City Manager Department >>>City of San Jose, CA USA >>>801 North First Street, Room 460 >>>San Jose, CA 95110-1704 >>>(408)277-4034 >>>(408)971-0134 TTY >>>(408)277-3885 FAX >>><http://www.rit.edu/~easi/webcast/cynthia.htm>http://www.rit.edu/~easi/web >cast/cynthia.htm >>><http://www.aasa.dshs.wa.gov/access/waddell.htm>http://www.aasa.dshs.wa.go >v/access/waddell.htm >>> >>> >>>-----Original Message----- >>>From: Leonard R. Kasday [<mailto:kasday@acm.org>mailto:kasday@acm.org] >>>Sent: Wednesday, June 02, 1999 7:41 AM >>>To: w3c-wai-ig@w3.org >>>Subject: How can we make Microsoft Publisher Accessible on the Web >>> >>>We have a problem with some documents we wrote in "Microsoft Publisher", a >>>program that makes formatted brochures etc. We want to publish it on the >>>web. But the HTML output is basically just one big image. In other words, >>>all the text and graphics are combined into an image. >>> >>>(Actually, it's a bit more complicated. There are several images. Also, it >>>happens with some documents but not others. It seems to depend on exactly >>>where text is placed on the page relative to the images. I can't give too >>>many details since it's being done by an outside contractor, not me: but I >>>have seen and verified the result: a bunch of images of text). >>> >>>There is a text output, but it's just plain text, no HTML, and no images. >>>So it's not the universal HTML output we'd really like. >>> >>>Finally, there's acrobat output but, besides the other problems with >>>Acrobat being discussed on this list, the files are huge. For example one >>>of our newsletters translates to a 15 mbyte PDF file. The text version is >>>only 18 kbytes and there are 5 images and some shaded bars . So HTML would >>>probably be a fraction of a MB, much smaller, in addition to being >>>universally accessible. >>> >>>Does someone know a way around this? For example, another page formatting >>>program that imports Microsoft Publisher and exports better HTML? Or some >>>setting in Publisher that guarantees that all text will translate to text, >>>not image? >>> >>>Or is there some feature of Microsoft Publisher that we are not using that >>>would help? Perhaps some update somewhere? >>> >>>Len >>>------- >>>Leonard R. Kasday, Ph.D. >>>Universal Design Engineer, Institute on Disabilities/UAP, and >>>Adjunct Professor, Electrical Engineering >>>Temple University >>> >>>Ritter Hall Annex, Room 423, Philadelphia, PA 19122 >>>kasday@acm.org >>>(215} 204-2247 (voice) >>>(800) 750-7428 (TTY) >>> >> >> >> >> >>------- >>Leonard R. Kasday, Ph.D. >>Universal Design Engineer, Institute on Disabilities/UAP, and >>Adjunct Professor, Electrical Engineering >>Temple University >> >>Ritter Hall Annex, Room 423, Philadelphia, PA 19122 >>kasday@acm.org >>(215} 204-2247 (voice) >>(800) 750-7428 (TTY) >> >Anne L. Pemberton >http://www.pen.k12.va.us/Pav/Academy1 >http://www.erols.com/stevepem/apembert >apembert@crosslink.net >Enabling Support Foundation >http://www.enabling.org > > > ------- Leonard R. Kasday, Ph.D. Universal Design Engineer, Institute on Disabilities/UAP, and Adjunct Professor, Electrical Engineering Temple University Ritter Hall Annex, Room 423, Philadelphia, PA 19122 kasday@acm.org (215} 204-2247 (voice) (800) 750-7428 (TTY)
Received on Monday, 19 July 1999 17:06:11 UTC