Responding to Philippe Verdy:
> There's no advantage because what you want to create is effectively another 
> markup language with its own syntax (but requiring new obscure characters 
> that most applications and users will not be able to interpret and render 
> correctly in the way intended by you, ...
Well, if the format became accepted as part of Unicode then appropriate 
applications could well be produced that would interpret the format and display 
an image in the desired place.
 > ... and with still many things you have forgotten about the specific needs 
 > for images (e.g. colorimetry profiles, aspect ratio of pixels with bitmaps, 
 > undesired effects that must be controled such as "moiré" artefacts).
The format is just at present a basic suggestion. Rather than just state what 
you consider what I have forgotten and dismiss the format, how about joining in 
progress and specifying what you consider needs adding to the format and 
perhaps suggest how to add in that functionality in the style that the format 
uses.
> You don't need new characters to create a markup language and its syntax. 
> Today the world goes very well with HTML(5) which is now the bext markup 
> language for document (including for inserting embedded images that don't 
> require any external request, or embedding special effects on images, such as 
> animation or dynamic layouts for adapting the document to the redering 
> device, with the help of CSS and Javascript that are also embeddable).
The two questions that I asked in my response to a post by Mark E. Shoulson are 
relevant here.
Suppose that a plain text file is to include just one non-standard emoji 
graphic. How would that be done otherwise than by the format that I am 
suggesting?
What if there were three such non-standard emoji graphics needed in the plain 
text file, the second graphic being used twice. How would that be done 
otherwise than by the format that I am suggesting?
> At least with HTML5 they don't try to reinvent the image formats and there's 
> ample space for supporting multiple images formats tuned for specific needs 
> (e.g. JPEG, PNG, GIF, SVG, TIFF...) including animation and video, and 
> synchronization of images and audio in time for videos, or with user 
> interactions. They are designed separately and benefit from patient 
> researches made since long (your desired format, still undocumented, is 
> largely under the level needed for images, independantly of the markup syntax 
> you want to create to support them, and independantly of the fact that you 
> also want to encode these syntaxic elements with new characters, something 
> that is absolutely not needed for any markup language)
Well it is undocumented apart from posts in this thread because I have put 
forward the format for discussion. A pdf document for consideration by the 
Unicode Technical Committee could be produced and submitted if there is 
interest in the format, the content of the pdf document perhaps including 
suggestions from this thread if any such suggestions are forthcoming.
> In summary, you are reinventing the wheel.
Well, this is progress, producing an additional format for expressing an image 
for application in various specific specialised circumstances.
William Overington
29 May 2015

Reply via email to