- From: Kevin Marks via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Aug 2016 18:48:35 +0000
- To: public-annotation@w3.org
On Thu, Aug 4, 2016 at 11:21 AM, Rob Sanderson <notifications@github.com> wrote: > That said, the review did reveal needs that aren't solved by unicode. The > properties are not only for embedded strings (which in JSON we can expect > to be unicode) but for arbitrary resources with URIs. I have no idea how > PDFs store text strings (for example) and how well implemented the control > characters are in those strings, but I can point you to many instances of > older or just badly implemented XML documents in a huge variety of > encodings. As these resources can take the role of the body of the > Annotation, the unicode proposal isn't sufficient to address the > requirements. > That seems even more aspirational then. I have no idea how you would test the utility of these properties if you don't know how to process the PDF/ ancient XML formats in question. The claimed need for these is to correctly present external resources to the user. How concretely would processingLanguage and textDirection allow you to do this with PDF or legacy XML? Do the libraries you use to parse and display them take such parameters? Is there a codebase you can point to that uses them? If not, I'm not sure how you could begin to build test cases for them. -- GitHub Notification of comment by kevinmarks Please view or discuss this issue at https://github.com/w3c/web-annotation/issues/335#issuecomment-237647089 using your GitHub account
Received on Thursday, 4 August 2016 18:48:43 UTC