changeset 16835:527c1561a0ad

spelling/grammar/wording

--- a/DOCS/tech/osd.txt	Sun Oct 23 14:25:56 2005 +0000
+++ b/DOCS/tech/osd.txt	Sun Oct 23 14:49:32 2005 +0000
@@ -1,50 +1,50 @@
-some draft of new osd engine:
-=============================
+draft of new OSD engine:
+========================
 written by A'rpi
-including ideas from maillist from Jiri Svoboda, Tobias Diedrich, Artur Zaprzala
-Michael Niedermayer, Felix Buenemann, LGB
+including ideas from mailing list from Jiri Svoboda, Tobias Diedrich,
+Artur Zaprzala, Michael Niedermayer, Felix Buenemann, LGB
 
 requirements:
 - be able to do partial rendering, within a given bounding box
-  usefull, when parts of osd are outside of teh image and has to be
-  updated only when osd changes, or even has different colorspace
+  useful when parts of the OSD are outside of the image and has to be
+  updated only when OSD changes, or even has different colorspace
 
 - text should be rendered in 2-pass way: 1. alpha 2. pixels
   so char's alpha won't overwrite previous char, and may be faster
-  
-- osd elements should be cached - so rendering once into the cache and
+
+- OSD elements should be cached - so rendering once into the cache and
   reuse this while it's unchanged
-  
-- colors support (csp could be YA, YUVA, RGB )
+
+- color support (colorspace could be YA, YUVA, RGB)
 
 - change brightness, saturation, hue of chars ???
 
 - way to disable alphablending, and use black outline (FAST_OSD now)
 
-- respect movie and monitor aspect, so osd is rendered/scaled correctly
-  eg. for svcd/anamorphic dvd with hardware scaling (now OSD is squashed)
+- respect movie and monitor aspect, so OSD is rendered/scaled correctly
+  eg. for SVCD/anamorphic DVD with hardware scaling (now OSD is squashed)
 
 - develop some text-based apps: osdterm, osdzilla etc ;)
 
-Ok. The basic idea of my design is using 'osd objects', a data structure
+Ok. The basic idea of my design is using 'OSD objects', a data structure
 in a 1 (or 2?) way linked list.
-There would be different object types, sharing type-dependent data in an
+There would be different object types, sharing type-dependent data in a
 union. The basic types: box, text, symbol, progressbar, group.
 
-Group would be a special type, grouping other osd objects together,
-with a common x,y and boundingbox. usefull for grouping symbol+progrbar
+Group would be a special type, grouping other OSD objects together,
+with a common x,y and boundingbox. Useful for grouping symbol+progrbar
 or multiline subtitle text.
 
-Each obj could have flags, for example:
+Each object could have flags, for example:
 - visible (set if we should display it)
 - color (set if it's YUVA not YA)
 - cached (set when there is a cached rendered variant)
 - bbox updated (should be set when recalc bbox, reset when change params)
 - several flags to control positioning. for example, x;y could be
-  absolute coord, or percent. flags to set left/center/right alignment...
+  absolute coordinates, or percent. flags to set left/center/right alignment...
 - start and end timestamp, to automagically set/reset visible flag
 
-ok, my first draft:
+OK, my first draft:
 
 typedef struct mp_osd_obj_s {
     struct mp_osd_obj_s* next;