Masataka Ohta <mohta at necom830 dot hpcl dot titech dot ac dot jp>
wrote:
FYI, your claim was:
: Here is an example of PDF-A that uses nothing but ASCII characters:
a PDF file whose *contents* were claimed to be pure ASCII
See above.
and now it is claimed that this demonstrates not only that the
contents of a PDF file cannot be plain ASCII, but also that HTML is
too unstable for a reduced-feature profile to be successful?
Are you saying your PDF-A file is good but your definition of PDF-A is
bad?
But, broken definition is worse than broken tools, which, even more
strongly, means we must not use profiled subset.
I really don't understand what you are trying to prove here, except
perhaps that I am a fool, and I don't understand in what way that
benefits the IETF.
Is it your claim that no PDF/A file could possibly exist without at
least one non-ASCII character in its contents?
Is it your claim that the "document properties" metadata, which of
course doesn't exist for a plain-text RFC, is essential to the nature of
a PDF/A RFC, and that no tool could exist that would not insert a
trademark symbol or other non-ASCII character into this metadata?
Or are you just trying to show that you are more clever than me?
--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf