E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 16 (In chronological order)

From: Chagnon | PubCom
Date: Wed, Oct 30 2013 5:22PM
Subject: Accessible GIS coordinates
No previous message | Next message →

Looking for recommendations on how best to present GIS coordinates in a PDF
tour book. The tour book has a narrative description of the location, along
with GIS coordinates.

2 questions:

1. The client’s original GIS format is Degrees / Minutes / Seconds.
Sample: 41° 24' 12.1674", 2° 10' 26.508"

In our screen reader tests, the minutes and seconds aren’t voiced regardless
of which Unicode character is used — Prime U+2032 or U+02B9, and
Double-Prime U+2033 or U+02BA.

Is there another symbol for minutes and seconds to use that is voiced by
screen readers? Is there another way to handle this?

2. Is there consensus on which GIS format to use? Three sample formats
follow.

· Decimal degrees: 41.40338, 2.17403

· Degrees, minutes and seconds: 41° 24' 12.1674", 2° 10' 26.508"

· Degrees and decimal minutes: 41 24.2028, 2 10.4418

Thanks all,

—Bevi Chagnon

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -

www.PubCom.com <http://www.pubcom.com/>; — Trainers, Consultants, Designers,
Developers.

Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.

New Sec. 508 Workshop & EPUBs Tour in 2013 — www.Workshop.Pubcom.com

From: Olaf Drümmer
Date: Wed, Oct 30 2013 5:47PM
Subject: Re: Accessible GIS coordinates
← Previous message | Next message →

Hi Bevi,

part of the problem might be that these are not unambiguous… - it could at least stand for inches or seconds. In other words - double prime can be more than one thing… As today's screen readers don't do a lot of context analysis they simply can't figure out whether it's an inch, a second, or what else… It looks like in this case Unicode did standardise a shape, not a character with a defined semantic.


Hmm - interesting problem.


Olaf




Am 31 Oct 2013 um 00:22 schrieb Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >:

> Looking for recommendations on how best to present GIS coordinates in a PDF
> tour book. The tour book has a narrative description of the location, along
> with GIS coordinates.
>
> 2 questions:
>
> 1. The client’s original GIS format is Degrees / Minutes / Seconds.
> Sample: 41° 24' 12.1674", 2° 10' 26.508"
>
> In our screen reader tests, the minutes and seconds aren’t voiced regardless
> of which Unicode character is used — Prime U+2032 or U+02B9, and
> Double-Prime U+2033 or U+02BA.
>
> Is there another symbol for minutes and seconds to use that is voiced by
> screen readers? Is there another way to handle this?
>
> 2. Is there consensus on which GIS format to use? Three sample formats
> follow.
>
> · Decimal degrees: 41.40338, 2.17403
>
> · Degrees, minutes and seconds: 41° 24' 12.1674", 2° 10' 26.508"
>
> · Degrees and decimal minutes: 41 24.2028, 2 10.4418
>
> Thanks all,
>
> —Bevi Chagnon
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - -
>
> www.PubCom.com <http://www.pubcom.com/>; — Trainers, Consultants, Designers,
> Developers.
>
> Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
> Accessibility.
>
> New Sec. 508 Workshop & EPUBs Tour in 2013 — www.Workshop.Pubcom.com
>
>
>
> > >

From: Jared Smith
Date: Wed, Oct 30 2013 5:54PM
Subject: Re: Accessible GIS coordinates
← Previous message | Next message →

Chagnon | PubCom wrote:

> Is there another symbol for minutes and seconds to use that is voiced by
> screen readers?

No.

> Is there another way to handle this?

No, not really. This should fall on the end user's system to read the
necessary characters. It should be apparent to most readers what the
numbers are, even if the characters aren't being read. And they could
read character-by-character if need be. I wouldn't worry about doing
anything special here.

> 2. Is there consensus on which GIS format to use?

This should probably be dictated by the client based on the system in
use. I see all three formats used regularly. A lot of systems I've
used show multiple formats.

Jared

From: Chagnon | PubCom
Date: Wed, Oct 30 2013 9:46PM
Subject: Re: Accessible GIS coordinates
← Previous message | Next message →

Thanks Olaf and Jared for your comments.

Yes, Unicode characters are an interesting problem. Our firm focuses on
complex, technical publications and periodicals and I'm often stumped why
today's screen reader software doesn't recognize or voice most of the
characters on a font.

I can view thousands of Unicode characters on an OpenType font, such as
Arial Unicode and Myriad Pro, and I can see the name or description for each
character. It's built into the code of the font. Since the data is there, I
wonder why screen readers read this information for some glyphs but not for
the majority.

In these tour books, it sure would improve comprehension for screen reader
users if even "prime" and "double prime" could be voiced. In our tests, the
characters were ignored and the numbers read straight through without a
pause or hint, forcing our testers to reread character by character to
decipher the coordinates. I guess if you read GIS data frequently you'd
figure things out quicker, but these tour books are for the ordinary
traveler who might not be all that familiar with GIS.

If anyone has knowledge as to why most characters aren't voiced by screen
readers, please let us know!

—Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com — Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2013 — www.Workshop.Pubcom.com

From: Olaf Drümmer
Date: Thu, Oct 31 2013 2:13AM
Subject: Re: Accessible GIS coordinates
← Previous message | Next message →

Hi Bevi,


Am 31 Oct 2013 um 04:46 schrieb Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >:

> I'm often stumped why
> today's screen reader software doesn't recognize or voice most of the
> characters on a font.

maybe you should let the vendors low about this….

A while ago the NVDA team told they'd voice most of the important Unicode codepoints but that they don't see any value in doing this for each and every code point. It seems prime and double prime might be among the less important ones. As the NVDA guys are very open minded - if they begin to hear they should include support fore more of these code points, especially including prime and double prime for GIS coordinates etc., they might simply add it.


Olaf

From: Jim Allan
Date: Thu, Oct 31 2013 8:15AM
Subject: Re: Accessible GIS coordinates
← Previous message | Next message →

did a test with JAWS 14

Degrees, minutes and seconds: 41° 24' 12.1674", 2° 10' 26.508"
reading by word (ctrl right arrow)-
"degree" spoken, minutes read as "apostrophe", seconds read as "quote".
reading by line "degree" spoken, minutes/apostrophe not spoken, "quote"
spoken.

Decimal degrees: 41.40338, 2.17403 was the fine no matter what mode the
reading happened. Unambiguous all the time.

Degrees and decimal minutes: 41 24.2028, 2 10.4418 was a slight pause
between the degrees and minutes. it read as forty-one twenty-four point two
oh two eight.

to me the decimal degrees are the cleanest and read the same way all the
time.


On Thu, Oct 31, 2013 at 3:13 AM, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Bevi,
>
>
> Am 31 Oct 2013 um 04:46 schrieb Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >:
>
> > I'm often stumped why
> > today's screen reader software doesn't recognize or voice most of the
> > characters on a font.
>
> maybe you should let the vendors low about this….
>
> A while ago the NVDA team told they'd voice most of the important Unicode
> codepoints but that they don't see any value in doing this for each and
> every code point. It seems prime and double prime might be among the less
> important ones. As the NVDA guys are very open minded - if they begin to
> hear they should include support fore more of these code points, especially
> including prime and double prime for GIS coordinates etc., they might
> simply add it.
>
>
> Olaf
>
> > > >



--
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

From: Jonathan Metz
Date: Thu, Oct 31 2013 11:38AM
Subject: Re: Accessible GIS coordinates
← Previous message | Next message →

Couldn¹t this be solved by using ActualText, since they are unambiguous as
Olaf points out.

>>No, not really. This should fall on the end user's system to read the
necessary characters. It should be apparent to most readers what the
numbers are, even if the characters aren't being read. And they could
read character-by-character if need be. I wouldn't worry about doing
anything special here.

On 10/30/13 7:54 PM, "Jared Smith" < = EMAIL ADDRESS REMOVED = > wrote:

>
>No, not really. This should fall on the end user's system to read the
>necessary characters. It should be apparent to most readers what the
>numbers are, even if the characters aren't being read. And they could
>read character-by-character if need be. I wouldn't worry about doing
>anything special here.


I would argue that only readers who may have seen coordinates would know
what these symbols represent. Users of screen readers for non-visual
related disabilities (for example, those with a CI) might require a more
specific explanation of the usage of the symbols.

Thanks,
Jon



On 10/31/13 10:15 AM, "Jim Allan" < = EMAIL ADDRESS REMOVED = > wrote:

>did a test with JAWS 14
>
>Degrees, minutes and seconds: 41° 24' 12.1674", 2° 10' 26.508"
>reading by word (ctrl right arrow)-
>"degree" spoken, minutes read as "apostrophe", seconds read as "quote".
>reading by line "degree" spoken, minutes/apostrophe not spoken, "quote"
>spoken.
>
>Decimal degrees: 41.40338, 2.17403 was the fine no matter what mode the
>reading happened. Unambiguous all the time.
>
>Degrees and decimal minutes: 41 24.2028, 2 10.4418 was a slight pause
>between the degrees and minutes. it read as forty-one twenty-four point
>two
>oh two eight.
>
>to me the decimal degrees are the cleanest and read the same way all the
>time.
>
>
>On Thu, Oct 31, 2013 at 3:13 AM, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi Bevi,
>>
>>
>> Am 31 Oct 2013 um 04:46 schrieb Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >:
>>
>> > I'm often stumped why
>> > today's screen reader software doesn't recognize or voice most of the
>> > characters on a font.
>>
>> maybe you should let the vendors low about thisŠ.
>>
>> A while ago the NVDA team told they'd voice most of the important
>>Unicode
>> codepoints but that they don't see any value in doing this for each and
>> every code point. It seems prime and double prime might be among the
>>less
>> important ones. As the NVDA guys are very open minded - if they begin
>>to
>> hear they should include support fore more of these code points,
>>especially
>> including prime and double prime for GIS coordinates etc., they might
>> simply add it.
>>
>>
>> Olaf
>>
>> >> >> >>
>
>
>
>--
>Jim Allan, Accessibility Coordinator & Webmaster
>Texas School for the Blind and Visually Impaired
>1100 W. 45th St., Austin, Texas 78756
>voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
>"We shape our tools and thereafter our tools shape us." McLuhan, 1964
>>>

From: Chagnon | PubCom
Date: Thu, Oct 31 2013 12:42PM
Subject: Re: Accessible GIS coordinates
← Previous message | Next message →

Jonathan Metz wrote:
"Couldn¹t this be solved by using ActualText, since they are unambiguous as
Olaf points out."

If only we could do that, Jonathan!

Neither MS Word nor Adobe InDesign allow designers to select one text
character, such as the prime glyph or any other dingbat character or symbol,
and set Actual Text for it.

In Word, Actual Text can only be applied to graphic objects. The utility is
actually on the Format Picture command.

In InDesign, Actual Text can only be applied to frames, that is to the
entire text or graphic frame not to just one character.

As an example, a normal publication layout in InDesign would have an entire
column of text in one frame and the glyph, like the prime or any other
non-standard glyph, is just a text character somewhere in the frame with the
rest of the regular text.

So, we can't apply Actual Text to the entire column's text frame.
We also can't select just one glyph and apply Actual Text to it.

We can, however, convert the glyph to a graphic, anchor the graphic into the
body text at the appropriate place, and put Actual Text on the graphic. But
that requires a ridiculous amount of time, especially over the 100+ pages of
a tour book with probably close to 1,000 of these glyphs. And then, when
editors do what they do — edit — this becomes a very messy layout to change.
In this tour book we're working on, this process would add several days of
production time just to make the GIS minutes and seconds glyphs accessible.

Therefore it's not going to happen and this book won't be as accessible as
it should be.

InDesign does a decent job of exporting anchored graphics into the correct
reading order/tag order when the layout is exported to PDF, but with Word,
we're always surprised by where it decides to place anchored graphics in the
exported PDF. They can end up anywhere in the PDF's tag tree/reading order.
And they require a ridiculous amount of time to correct in Acrobat.

The best solution is 2-fold:
1) Screen Reader manufacturers pick up the glyph's name/description from the
font information and voice it.
2) Adobe and Microsoft develop tools to let Actual Text be applied to
individual glyphs. Sort of like the <ABBR> tag in HTML (which isn't
available in Word, InDesign or PDF).

Someone has to figure out a solution to this.

Those of us producing professional publications run into the problem daily.
There are countless times we're using font glyphs as visual shortcuts of
communication, like the end-of-story box at the end of the story.

In this tour book, a character on the Wingdings font is used to visually
flag key scenic points. I have no practical way to convey that visual
information to a screen reader user.

Will the final PDF file be accessible? Yes.
Will it convey all the information to screen reader users? No. I don't have
the tools to do that.

—Bevi
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com — Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2013 — www.Workshop.Pubcom.com

From: Jonathan Metz
Date: Thu, Oct 31 2013 1:28PM
Subject: Re: Accessible GIS coordinates
← Previous message | Next message →

Sorry Bevi,

I thought you were ending with PDF as the final format, not leaving them
as Word or InDesign. In Acrobat, you would create a span tag, select it,
then select the character in question, then right-click and choose ¡°Create
tag from selection¡±. In the Span tag properties you can change the Actual
Text there.

This is similar to what I do when I have images as bullets in Lists in
PowerPoint or just getting the bullet characters in Word to end up under a
Label tag since Word and PowerPoint assembles the contents of lists in the
LBody tag.

Jon



On 10/31/13 2:42 PM, "Chagnon | PubCom" < = EMAIL ADDRESS REMOVED = > wrote:

>Jonathan Metz wrote:
>"Couldn©öt this be solved by using ActualText, since they are unambiguous
>as
>Olaf points out."
>
>If only we could do that, Jonathan!
>
>Neither MS Word nor Adobe InDesign allow designers to select one text
>character, such as the prime glyph or any other dingbat character or
>symbol,
>and set Actual Text for it.
>
>In Word, Actual Text can only be applied to graphic objects. The utility
>is
>actually on the Format Picture command.
>
>In InDesign, Actual Text can only be applied to frames, that is to the
>entire text or graphic frame not to just one character.
>
>As an example, a normal publication layout in InDesign would have an
>entire
>column of text in one frame and the glyph, like the prime or any other
>non-standard glyph, is just a text character somewhere in the frame with
>the
>rest of the regular text.
>
>So, we can't apply Actual Text to the entire column's text frame.
>We also can't select just one glyph and apply Actual Text to it.
>
>We can, however, convert the glyph to a graphic, anchor the graphic into
>the
>body text at the appropriate place, and put Actual Text on the graphic.
>But
>that requires a ridiculous amount of time, especially over the 100+ pages
>of
>a tour book with probably close to 1,000 of these glyphs. And then, when
>editors do what they do ¡ª edit ¡ª this becomes a very messy layout to
>change.
>In this tour book we're working on, this process would add several days of
>production time just to make the GIS minutes and seconds glyphs
>accessible.
>
>Therefore it's not going to happen and this book won't be as accessible as
>it should be.
>
>InDesign does a decent job of exporting anchored graphics into the correct
>reading order/tag order when the layout is exported to PDF, but with Word,
>we're always surprised by where it decides to place anchored graphics in
>the
>exported PDF. They can end up anywhere in the PDF's tag tree/reading
>order.
>And they require a ridiculous amount of time to correct in Acrobat.
>
>The best solution is 2-fold:
>1) Screen Reader manufacturers pick up the glyph's name/description from
>the
>font information and voice it.
>2) Adobe and Microsoft develop tools to let Actual Text be applied to
>individual glyphs. Sort of like the <ABBR> tag in HTML (which isn't
>available in Word, InDesign or PDF).
>
>Someone has to figure out a solution to this.
>
>Those of us producing professional publications run into the problem
>daily.
>There are countless times we're using font glyphs as visual shortcuts of
>communication, like the end-of-story box at the end of the story.
>
>In this tour book, a character on the Wingdings font is used to visually
>flag key scenic points. I have no practical way to convey that visual
>information to a screen reader user.
>
>Will the final PDF file be accessible? Yes.
>Will it convey all the information to screen reader users? No. I don't
>have
>the tools to do that.
>
>¡ªBevi
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>-
>- - - - - - - - - - - - - - -
>www.PubCom.com ¡ª Trainers, Consultants, Designers, Developers.
>Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
>Accessibility.
>New Sec. 508 Workshop & EPUBs Tour in 2013 ¡ª www.Workshop.Pubcom.com
>
>
>>>

From: Chagnon | PubCom
Date: Thu, Oct 31 2013 2:08PM
Subject: Re: Accessible GIS coordinates
← Previous message | Next message →

We are producing PDFs as the final format (although sometimes Word.docx are
the finals).

Your workaround in Acrobat is a solution and we thought about doing that a
few weeks ago, but it's not practical in a professional publishing
environment because it doesn't solve the problem in the source document
(such as Word or InDesign). We and our clients are producing hundreds of
pages a day . . . a day.

In this particular tour book, there are close to 1,000 glyphs that we would
need to hand-fix in Acrobat with the span tag with Actual Text.

Since there is no way to automate this in Acrobat (not that I know of!), we
would have to search for each glyph, select it, make a new span tag from it,
and add the Actual Text to the span tag.

And then repeat this 1,000 times.

If it took 1/2 minute per glyph, that's more than 8 hours of labor, nonstop,
no breaks.

This is not feasible! Even if I provided massive amounts of stimulants to my
staff (caffeine, sugar, chocolate, whatever) they'd mutiny within an hour!

Plus, as many of us have discussed on this list, it's always better to
correct the source document from which we export out a hopefully perfect
PDF. Well, that's the goal.

In a normal publishing production workflow, we go through many iterations of
a document. There are always changes and more changes to a so-called "final
PDF" by clients, editors, authors, directors of the organization etc. We
always have to go back to the source document, make substantial changes, and
re-export to PDF at least 2-3 times before it's finally finished. And these
are "final" PDFs we're making, not preliminary versions.

That's the normal workflow for publishers. Think of it as a whirlwind or
tornado of unending chaos.

So I need to be able to create a totally accessible source document in Word
and InDesign so that I can export out a totally accessible PDF from them,
and do that each time the client makes changes to the source which forces a
new PDF to be exported.

I need the tools in Word and InDesign. By the time we're in Acrobat, it's
too late in the workflow to fix items like this unless it's just one or two
in the document.

-Bevi
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2013 - www.Workshop.Pubcom.com

From: Michael Rollins
Date: Fri, Nov 01 2013 1:31PM
Subject: Re: Accessible GIS coordinates/Lack of Tools
← Previous message | Next message →

Bevi Chagon wrote:
The best solution is 2-fold:
1) Screen Reader manufacturers pick up the glyph's name/description from the
font information and voice it.
2) Adobe and Microsoft develop tools to let Actual Text be applied to
individual glyphs. Sort of like the <ABBR> tag in HTML (which isn't
available in Word, InDesign or PDF).


For those of us involved in high volume production of accessible documents, there is a sad lack of effective and efficient tools with which to both produce consistent source files and quickly make the necessary clean ups required in Acrobat. I work primarily with technical documents as deliverables to the Federal government, frequently with many tables, graphics, and formulas (containing glyphs). The source documents can come from numerous authors with varying skills in producing Word or InDesign files. They almost always have to be altered to be able to be used as source documents.

I have the same issue as Bevi with glyphs in formulas frequently found in these technical files. There simply aren't the tools in any of these programs to allow the work in the source file necessary to produce PDFs that can be finalized quickly.

Tables in particular suffer from a lack of editing tools. Table editors in Word and Indesign, while making nice looking tables, do not assign all Type and Scope attributes correctly. Scope attributes have to be assigned in Acrobat. There is no means at all for assigning linked headers in complex tables in Word or InDesign, let alone a way of automating it. In Acrobat, the Table Editor will let you assign linked headers, but only in the most maddeningly slow and inefficient way imaginable. Wide tables rotated to fit on portrait pages are quite common. Acrobat's Table Editor will not work at all with rotated tables from an InDesign source file. The only way in Acrobat to assign scope to headers in rotated tables is through editing the attribute property for each and every instance of a header file, another maddeningly slow and frustrating job. In documents with hundreds of tables, clients always want to know why work hours expand into the hundreds. They need look no further tha
n the weak tools provided by software vendors.

I could go on, but the point is that software vendors have done little to keep producing accessible PDFs from being drudge work for anything but the simplest of documents.

Mike

From: Olaf Drümmer
Date: Fri, Nov 01 2013 2:00PM
Subject: Re: Accessible GIS coordinates/Lack of Tools
← Previous message | Next message →

Apologies for the blatant plug but…:

Am 1 Nov 2013 um 20:31 schrieb Michael Rollins < = EMAIL ADDRESS REMOVED = >:

> There is no means at all for assigning linked headers in complex tables in Word or InDesign, let alone a way of automating it.

that means is called axaio MadeToTag, it is a plug-in for InDesign CS 5.5, CS 6 or CC on Mac or Windows (sorry, does not work with Word), and a fully functional demo can be found at http://www.axaio.com/doku.php/en:products:madetotag

While it does not automate tagging of advanced tables, it makes the necessary manual steps very easy (including intuitive visual feedback). And it aided with a couple of other tasks to prepare for export to tagged PDF (including fixing a couple of quirks in InDesign's tagged PDF export).

Olaf
(I happen to work for axaio software, the maker of this and a couple of other InDesign plug-in, my views on the product may be biased ;-) )

From: Chagnon | PubCom
Date: Fri, Nov 01 2013 2:51PM
Subject: Re: Accessible GIS coordinates/Lack of Tools
← Previous message | Next message →

Mike Rollins wrote:
"I could go on, but the point is that software vendors have done little to
keep producing accessible PDFs from being drudge work for anything but the
simplest of documents."

Well said, Mike.
Mike didn't exaggerate when he said hundreds of hours on some documents.
That's just the accessibility part, not the writing, researching, editing,
design, and production.

Asking the software manufacturers and AT vendors "nicely" hasn't worked so
far.
I wonder how many lawsuits it will take before we see any change in
corporate behavior.

-Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2013 - www.Workshop.Pubcom.com

From: Michael Rollins
Date: Sat, Nov 02 2013 8:32AM
Subject: Re: Accessible GIS coordinates/Lack of Tools
← Previous message | Next message →

Olaf, thank you for the information about MadeToTag. I was not aware of this plug-in and will definitely check it out.

Mike

From: Michael Rollins
Date: Sat, Nov 02 2013 11:12AM
Subject: Re: Accessible GIS coordinates/Lack of Tools
← Previous message | Next message →

Olaf, I downloaded and installed MadeToTag for my Mac. I've only tested the Table Structure Editor. It's by far the best table editor I've run across. The Smart Headers function provides the ability to quickly assign linked headers with a point-and-click interface that is easy to use. It is also the only editor I've run across that allows you to set row headers as well as col headers in InDesign. The only criticism I have is that the editor does not assign a Scope attribute (row, col, both) when the Type tag is applied. The federal agencies that I deal with in the U.S. require the Scope attribute to be set for table head tags. This will require editing each table in Acrobat to assign a scope attribute to heads. It would be great if this function could be added to the editor. Incidentally, the editor works with rotated tables in InDesign, a real plus. I'm anxious now to try some of the other features of this plug-in.

Thanks again for bringing this to my attention.

Mike

From: Olaf Drümmer
Date: Sat, Nov 02 2013 3:04PM
Subject: Re: Accessible GIS coordinates/Lack of Tools
← Previous message | No next message

Hi Mike,

thanks a lot for the kind feedback!


I will have my engineers look into this right away (the next update - a few weeks away - should have this fixed).


Olaf



Am 2 Nov 2013 um 18:12 schrieb Michael Rollins < = EMAIL ADDRESS REMOVED = >:

> Olaf, I downloaded and installed MadeToTag for my Mac. I've only tested the Table Structure Editor. It's by far the best table editor I've run across. The Smart Headers function provides the ability to quickly assign linked headers with a point-and-click interface that is easy to use. It is also the only editor I've run across that allows you to set row headers as well as col headers in InDesign. The only criticism I have is that the editor does not assign a Scope attribute (row, col, both) when the Type tag is applied. The federal agencies that I deal with in the U.S. require the Scope attribute to be set for table head tags. This will require editing each table in Acrobat to assign a scope attribute to heads. It would be great if this function could be added to the editor. Incidentally, the editor works with rotated tables in InDesign, a real plus. I'm anxious now to try some of the other features of this plug-in.
>
> Thanks again for bringing this to my attention.
>
> Mike
> > >