Since the control emits bizzare non-standard HTML, I'm wondering if it has any practical value.
The control emits font tags!
How are others dealing with it? Do you do some sort of RegEx replace on the text?
Or am I missing something?
Does it have a value? Yes. Is it practical? That depends. How much work are you willing to do to get something useful out of it?
I had to use the RTC to create a chat window for a chat app that was built on Jabber. I wound up having to parse every line of every chat message, check its textwidth, GREP out the bogus HTML (TextFormat and Font tags) while leaving the styling tags (bold, italic, etc.) then shift it onto a queue that would scroll upwards as new messages were sent and received. I had to keep an onscreen buffer of 200 of these lines (taking care not to delete partial messages at the end of the queue). I also had to plot where the emoticons — :) ;) :-) and the like — were located, find out their exact locations, and then draw the emoticon images onto a sync-scrolled Canvas that exactly matched the position of the chat output window. All this while keeping the text selectable and letting people copy and paste it, complete with emoticon tokens that reverted to whatever text smiley upon pasting into the input field.
Was this a lot of work? You bet it was. Was the product ultimately useful? I like to think so. It was pretty cool, in fact. And as it was one of the first Flex projects I ever worked on, it taught me a lot.
Do I wish Adobe supported real, non-gimped HTML? Absolutely.
Short answer: Getting something out of the RTC is a bitch, but probably still faster than doing anything similarly useful in Java or C++. YMMV.
Related
I'm using Windows Narrator and a version number like 2.3.96 is being reader as a date "2nd March, 1996". How do I handle version numbers for screen readers? I see some answers suggested using a label and spell out the dots, like: aria-label="2 dot 3 dot 96". Is there a better way to do this?
There are already several similar questions on stackoverflow and elsewhere about numbers and other things that aren't pronounced as the page writer expects.
The same answer applies to version numbers interpreted as dates: you'd better do nothing and write it without anything special.
The problem is that the pronunciation of numbers depends on many layers:
The browser and its way to expose accessibility tree.
The OS, the screen reader and its settings. For example, Jaws offers many options that can change how numbers and dates are interpreted and spoken out.
The voice used. The same screen reader, on the same OS, with the same browser, but with different voices can indeed read the same text very differently.
You may try several things, like separating it in a different <span>, adding or removing spaces, writing "dot" via aria-label, etc.
However, by doing so, you are very likely to improve the pronunciation for some users, while degrading it for most others. The combinations of OS, browsers, screen readers, and voices are too huge to be able to test everything.
So the best is to keep pragmatic and don't do anything special. Keep your version number written as it is usually done everywhere.
Screen reader users are generally used to such pronunciation quirks and can, if necessary, adjust options and set up dictionaries.
Short Answer
Use <p aria-label="Version 2 point 3 point 96">Version 2.3.96</p>, this will get parsed correctly in most popular screen readers. Make sure there are no <spans> splitting the version number from the text, use an aria-label as overkill / a backup.
Long Answer
Normally I would advise to never interfere with the way a screen reader pronounces things, as #QuentinC has suggested.
However in this circumstance I would say that you do want to try and fix this problem, as hearing a date read where there should be a version number could be very confusing (was it the date the software was written, is it the date the company was formed? Who knows!).
This is a parsing problem in the screen reader, very different from problems most people have where they don't like the way something is read, please only follow the advice below for this one example only.
Fix one, change your markup.
You didn't add your markup but the below explanation is based on my testing.
This problem will actually fix itself (at least in JAWs, NVDA and VoiceOver from my testing) by simply adding 'Version' before the version number.
My guess is you have the version number in a format similar to the following:
<p>Version <span>2.3.96</span></p> or <p>2.3.96</p> without the word 'version'.
By removing the <span> in the first example JAWS, NVDA and VoiceOver read the following correctly in my testing:
<p>Version 2.3.96</p>
Once the <span> is added around the version number the context of the numbers is lost (text within <span> elements is evaluated on it's own) so a screen reader will try and parse it on it's own, without any context, and decide it is a date.
Surely using aria-label will fix it though?
Also aria-label will probably not work on static elements (<div>, <span> etc.) that do not have a role that indicates they are an active element, so odds are it will not work anyway for you.
For that reason I would not recommend trying to fix this problem with aria-label alone, however adding it for the screen readers that do take it into consideration is a step that would not hurt.
This is the only time I have ever recommended interfering with how a screen reader talks, please do not take this as a step to solve other pronunciation problems as this is a parsing problem not a pronunciation problem.
Taking that into account I would recommend you use the following:
<span aria-label="Version 2 point 4 point 99">Version 2.4.99</span>
With either a <span>, <p> or other content block surrounding it.
I want to create a macro, so that after I draft an email in Outlook it will be reformatted so that each word is a different font, size, color, and highlight.
Ideally, I would be able to constrain fonts, font sizes, and highlight frequency to maintain readability.
The goal is to achieve this kind of transformation.
I've never even attempted a project like this. What tool would most effectively implement this? Would I be able to package it and share it with others?
I want to use this as a learning opportunity, but need a kick in the right direction for what I need to understand to start.
First of all: I hope you never intend to actually send a message like that to anyone. If you do, the gods of Email will come down and squash you.
Now: you can use Outlook VBA and the MailItem.HTMLBody Property to set or modify the HTML text that is the body of the email. See e.g. here.
But be aware that the CSS support of Outlook is extremely limited, so you'd better use HTML tags to format the text, not CSS.
Suppose you're developing a web site and blind users will be a significant chunk of your target market. If the web site includes document editing functionality, what would be appropriate WYSIWYM tools? Are languages like Markdown, Textile and Wiki Formatting really accessible or are they inconvenient to blind users?
I'm a blind programmer and while I haven't used most of the languages you mention I've found that any markdown language is fairly easy to use if you have the desire to learn it. I've had no problem using either HTML or several markup languages for wiki's. Part of it will depend on how invested the users are in your site. If it's a site that will be visited infrequently or for short periods of time, it's much less likely that a user will take the time to learn the required markup whether they are blind or not. Unfortunately, I have not found an accessible JavaScript WYSIWYG editor but I find it easier to manually enter the markup so haven't looked very hard.
the first question is: how important is semantic structure? could you get away with plain text. You could do simple parsing like treating blank lines as paragraph markers, treating a series of lines which begin with * as a bulleted list, identify URLs and make them into links, etc.
As a blind developer myself, I have no problem in understanding languages like Markdown. But if it's a syntax I'm unfamiliar with, I'll only learn it if I expect to use the site very often, or care deeply about the content.
Two final thoughts come to mind: while I certainly experience some accessibility challenges using TinyMCE, you could develop something much simpler - provide less than 10 formatting options, like inserting hyperlinks, making lists, centering text, setting the style (such as heading) etc.
And lastly, when I talk to non-technical blind people, they often just write their content in Word and paste into a wiki or blog post. This sounded strange when I first heard it, but it does make sense. So an ideal solution would accept pasted in content.
In closing - it depends how important this is, and how much effort you want to expend. Maybe a Markdown editor with a live preview (like on this site), buttons for inserting simple formatting like URLs, and the ability to paste in rich text would tick all boxes :-)
On a web page, the most accessible embedded text editor for blind users is one that uses standard HTML, such as a <textarea> element, with a corresponding <label> element:
<label for="editor">Enter your text here using wiki markup:</label>
<textarea id="editor"></textarea>
If a WYSIWYM tool is built using standard accessible HTML, then blind users can easily enter text into it, with full confidence that they're entering text in the right place. Then the question becomes: Which is the better markup language? They all require memorization, but some may be more intuitive than others. One way to find out which is best would be to do some usability testing with a wide variety of target users. Also be sure to providing easy, accessible access to syntax help.
Picture yourself working in pure text 80x4 display (just open a console and resize appropriately), then use vi/emacs/ed and you'll soon realize what markup will get in the way.
Try to do as much work as possible to understand plain text, else use light markup like POD, finally things like AsciiDoc are very powerful but needs training.
I don't know about WYSIWYG/WYSIWYM tools, but I do know that complying with W3C standards (especially their HTML5 en CSS3 drafts) while writing your own editor code will help a lot.
In CSS you can specify speed and intonation of speech. In HTML you can specify alternative text (alt attribute in many elements) that screen readers are compatible with. Be sure to know when to use the abbr and the acronym elements. Use the former when you want the screen reader to read the meaning of an abbreviation and the latter when the acronym should be read as a word (e.g. ASAP, NATO and OS).
For the editor itself, I recommend creating a WYSIWYG editor that uses divs and spans. Screen readers will understand easily the structure of a document. For the current line, use a text box; for every other line that's not being edited, convert the contents immediately to valid HTML.
If you find a good tool, be sure to post it here. I'm looking for one too. :-)
I'm new to QT, and am trying to figure out the best means of creating a WYSIWYG editor widget for a custom markup language that displays simple text, images, and links. I need to be able to propagate changes from the WYSIWYG editor to the custom markup representation.
As a concrete example of the problem domain, imagine that the custom markup might have a "player" tag which contains a player name and a team name. The markup could look like this:
Last week, <player id="1234"><name>Aaron Rodgers</name><team>Packers</team></player> threw a pass.
This text would display in the editor as:
Last week, Aaron Rodgers of the Packers threw a pass.
The player name and the team name would be editable directly within the editor in standard WYSIWYG fashion, so that my users do not have to learn any markup. Also, when the player name is moused-over, a details pop-up will appear about that player, and similarly for the team.
With that long introduction, I'm trying to figure out where to start with QT. It seems that the most logical option would be the Rich Text API using a QTextDocument. This approach seems less than ideal given the limitations of a QTextDocument:
I can't figure out how to capture navigation events from clicking on links.
Following links on click seems to only be enabled when the QTextEdit is readonly.
Custom objects that implement QTextObjectInterface are ignored in copy-and-paste operations
Any HTML-based markup that is passed to it as Rich Text is retranslated into a series of span tags and lots of other junk, making it extremely difficult to propagate changes from the editor back to the original custom markup.
A second option appears to be QWebKit, which allows for live editing of HTML5 markup, so I could specify a two-way translation between the custom markup and HTML5. I'm not clear on how one would propagate changes from the editor back to the original markup in real-time without re-translating the entire document on every text change. The QWebKit solutions looks like awfully bulky to me (Learning WebKit along with QT) to what should be a relatively simple problem.
I have also considered implementing the WYSIWYG with a custom class using native QT containers, labels, images, and other widgets manually. This seems like the most flexible approach, and the one most likely not to run into unresolvable problems. However, I'm pretty sure that implementing all the details of a normal text editor (selecting text, font changes, cut-and-paste support, undo/redo, dragging of objects, cursor placement, etc.) will be incredibly time consuming.
So, finally, my question: are there any QT gurus out there with some advice on where to start with this sort of project?
BTW, I am using QT because the application is a desktop application that needs platform independence.
Given that I got no advice here, I decided to go with the QTextEdit approach, although I'm actually using a QTextBrowser that is set to be editable so that I can capture link navigation events. I will be using QTextCharFormat's with the link names set to unique identifiers in order to convert from the QTextEdit back to the custom markup. The QTextEdit supports images already, so I won't have to deal with those.
I think I will hit the biggest roadblocks with the fact that I need to be able to insert/grow/shrink tables whose cells can have Excel-style functionality. I have not yet figured that whole process out.
I am working on an ASP.Net web application that must print dynamically created labels on standard Avery-style label sheets (one particular size, so only one overall layout). The labels have a variable number of lines (3-6) and may contain either lines of text or a graphic barcode image.
Our first cut, that I inherited, used monospaced fonts to reduce the formatting issues, but that did not allow enough text to the fit on the labels and the customer was dissatisfied. Basically it was formatted text.
My next version used TABLEs, DIVs, CSS, and a bit of JavaScript calculations to format the labels using proportional fonts. It still required a bit of tweaking (the user had to set their print margins correctly and turn off the print headers and footers), but it seemed to work.
However, it seems that there are some variations on how different printers render the text (WYS ain't WYG), so even though we tested on different browsers using at least two different printers (an inkjet and a laser printer), some user's labels don't line up. Slight margin variations can be adjusted by adjusting the margins on the page setup dialog, but the harder problem is that the inter-label spacing can be off by a tiny fraction of an inch, so that if the first label is pretty well centered, by the end of the page the label text and images have crawled off the top or bottom of the labels.
We are about to the point of switching to generating Word, Excel, or PDF output which is going to take quite a bit of development time and possible add extra steps in the printing process.
So, does anyone have any suggestions on how to do an HTML/CSS layout that will precisely render on different types of printers? I don't really care if the line/word breaks are a bit different, but I need to be able to predictably position the upper left corners of each label area.
Right now the labels flow down the page in a table and we have been tweaking the box model of the cells and internal DIVs to make them a uniform height. I suspect that using absolute positioning of each element may be the best answer, but that is going to be tricky as well due to the ASP.Net generation of the label elements. If I knew for sure that would work, I would rather try it than throw away everything we have to go to a different generation method.
Slight Update:
Right now I'm doing some tests with absolute positioning - setting only the top and left coordinate of a containing block element. So far there are minor variations on the offset onto the page (margins, paper alignment, etc.), but all browsers and printers tested put the elements in exactly the right spots relative to each other. I appreciate the PDF tips, but does anyone know of additional "gotchas" on using absolute positioning this way?
Update:
For the record, I rewrote the label printing portion using iTextSharp and it works perfectly - definitely the way to do this in the future...
Forget HTML and make a PDF. HTML printing is extremely variable - not just across browsers but across different versions of the same browser. PDF is a lot easier.
Even if you get it exactly right with one browser / font setup / printer / phase of the moon, it will be the most fragile thing you've ever had to maintain. No matter how long you think it will take to make a PDF (and it's not really that hard as there are some free libraries out there), HTML will ultimately take a lot more of your time. PDF readers are widely deployed and print more consistently than even Word files.
The web is not a format that is guaranteed to get consistent print results. Given the standard support for label printing with MS Word, and the relative ease of automation and generation, I would strongly recommend going that route.
I'm not aware of ANY method to get percise printing across all types of browsers, operating systems, and printers when using web content.
"precisely" and "printing" aren't two words that really work together that well. I did an OCR/OMR application a year or so ago, and even when building a PDF I saw significant differences between different print drivers and such. Because of that, my gut is to tell you that you might not have 100% success.
If CSS and layout issues don't work that well for you, you might need to resort to building the labels as images using GDI+ -- at least that way you can use GetFontMetrics() and such.
Good luck!
I had a similiar issue and the answer is you can't do it. Instead, I generated a PDF file in realtime using iTextSharp and passed that to the response.
Using SQL Server Reporting Services, I generate a PDF to send to the printer, but it can be seen as HTML on the screen using the control you can include in your web pages. There are RDLC files that are available on the internet to print to various Avery formats.
I rewrote the SharpPDFLabel code that was mentioned back in 2011 this week as I needed it to be a lot more flexible (and to work with the current iTextSharp library).
You can get it here:
https://github.com/finalcut/SharpPDFLabel
I added the ability to specify the contents of each individual label if you want (or to continue creating a sheet of identical labels too). By extending the LabelDefinition class you can specify the layout of your labels pretty easily.
I also struggled with the HTML/CSS approach due to the inconsistent printing behaviour across browsers.
I created a C# library to produce Avery Labels from ASP.NET which I hope you might find useful:
https://github.com/wheelibin/SharpPDFLabel#readme
You can add images and text to the labels, and it's easy to define more labels types.
(I use it for barcode labels, the barcode is generated as an image and then added to the label using this library.)
Cheers
Add a few options to your app that let users adjust spacing for their particular configuration. You could include this right on the label if you want, and style it away via media selectors, but you'll probably want to persist them somewhere, too.
Flash is also good method to push a printable like a label albeit a little more complex to implement and maintain. In most cases it displays much quicker than a PDF and you can embed it into the design of the page and simply add a "Print" button within the flash.
I did this several years ago when we were using HTML and PDF to generate confirmation receipts. HTML is "ok" but is at the mercy of the end users web browser so we quickly dumped that method. PDF's are good as long as they have a PDF reader, which to our surprise a lot of our customers did not. So that was dumped as well after we switched to a FLASH version using a simple flash movie that included a few dynamic text areas and a "print" button. I communicated the data between the page and flash using a few flash vars. You can also use web service.
When I need something more than just simple text I use the free community edition of the PDF Generator component from DynamicPDF.com. It works great and is very quick.
I just went through the same thing. Ended up switching and making a short little JSF app (running on Glassfish) that uses JasperReports to print directly to the lable printer. Push button, instant label at the printer, don't even have to view it on-screen if you don't want to since Jasper can directly output to printer (as well as PDF in browser).