Understood. I have the same issue when laying text on still photos. One image acts as a mask for the other.
Deliberately nit picking: *data* or *video*? I.e., a data stream could take a string of text and render it *in* the DVD player before injecting it onto the screen. OTOH, *video* just requires the player to be able to superimpose two images -- one with an alpha channel.
E.g., PiP on a TV is handled by overlaying *video*. But, closed captioning is handled by a character generator *in* the TV synthesizing the text on the fly.
OK. But, within those -- and, with the proper authoring tools -- could I put a 720x576 image of a car on top of the real video?
Of course.
I should explore this -- if only to be *aware* of a capability that I might opt to use/abuse at some later date.
E.g., as long as the restrictions aren't *too* severe, it could be an effective PiP tool to augment a presentation by allowing the presenter/viewer to selectively turn that feature on/off to get additional information from the presentation that wouldn't be worth the screen real estate to present, otherwise!
Ack! The *last* thing I need is "yet another font"! :>
I have a machine that actually serves them up for me (so the *other* machines don't need to waste disk space on fonts that are only occasionally used)
I also have tools to build "fonts". E.g., one of the decorative fonts that I use in my publications replaces periods ("full stops") with little "drops" (I call the publications "Brain Drops" as they represent personal "brain dumps").
On a sunny day (Fri, 18 May 2012 11:33:03 -0700) it happened Don Y wrote in :
It is basically (if you must) a data stream holding bitmaps. If you go here:
formatting link
and scroll down looking for submux-dvd', I wrote that as extension to some code by unknown author I found for Chinese Video disks so it could also do DVD. If you look at the code you will see it is simply a multiplexer (that is why submux) that takes as input .bmp (bitmaps), were the filename of each bitmap is listed in a control file, the control file looks like this: frame4809.bmp 00:03:12:36 00:03:17:64 544 72 94 432 0 15 15 15 0 1 2 15 frame4941.bmp 00:03:17:64 00:03:22:24 520 72 106 432 0 15 15 15 0 1 2 15 frame5056.bmp 00:03:22:24 00:03:29:72 504 72 113 432 0 15 15 15 0 1 2 15 frame5243.bmp 00:03:29:72 00:03:33:12 504 72 112 432 0 15 15 15 0 1 2 15 frame5328.bmp 00:03:33:12 00:03:41:60 584 72 71 432 0 15 15 15 0 1 2 15 frame5540.bmp 00:03:41:60 00:03:45:96 360 36 184 466 0 15 15 15 0 1 2 15 frame5649.bmp 00:03:45:96 00:03:52:88 384 72 172 432 0 15 15 15 0 1 2 15 frame5822.bmp 00:03:52:88 00:03:55:04 392 36 170 466 0 15 15 15 0 1 2 15
Thats is start time, end time, size (h,v), position on screen, and the transparency, color. These pictures are put in the video stream.
We have, in Europe, something called 'teletext' or 'Ceefax', or 'Videotex' it is in analog TV a digital stream transmitted in the vertical interval, and in digital TV on a separate PID (stream) in the digital transport stream (.ts) It looks like this:
formatting link
There are several chips that can generate it with a hardware character generator, here it is generated by my software with a non standard font. There is block graphics, 9 field little graphics characters located in ASCII code 130(dec) and up. That is how they make the big characters and also sometimes all sorts of artistic pictures. Anyways you can look at the source code how it works http://panteltje/panteltje/xkrs/ it is more complicated than I just wrote.
Yes I think so, but I have not tried, you are still bound by outline etc.
For better quality subtitles I decode the mpeg2 or whatever to YUV, and render directly into the YUV, then re-encode again that way you can do anything you want. even animations, that is what this site shows, (scrolling titles for example) So I gave the wrong link in the previous posting, related to the 'overlays' (you want the DVD page for that). The disadvantage of direct rendering is that usually the decoding / encoding process decreases picture quality (but really often not even perceptible for an expert), and takes a long time. I wrote that soft (subtitler-yuv) around the year 2000 IIRC, and then on a single 1GHz it took all night for a 1 hour production. These days it is easy in real time with the processor power we have..
I wrote the xste subtitle editor (not to be confused with some Xilinx software), and that makes synchronizing the subs to the video or audio (you do not always need to see the video when translating, only if you have context problems or some on screen message needs to be translated) a piece of cake. But it still takes a long time to translate an hour text into decent subs. At one time I had many people using xste, but I lost contact, or rather broke it off when somebody send a cease and desist because perhaps my DVDs were better than their original ones... copyright insanity, money, whetever. I do know xste was used as a bases by some other guys IIRC in South America for an other Linux subtitle editor. There was also a MS subtitle editor called 'Substation Alpha', free, but worked very differently. This was the only Linux subtitle editor as far as I know. I constructed a simple picture manipulation language 'PPML', Panteltje Picture Manipulation Language', the name is wort of a joke towards ppm picture format, and that can do simple animations, like what you need for scrolling text, but only when redering directly into the video of course. No way can you do that with bitmaps.
But, no, by "controls" I meant "control SYSTEM". I think the "traditional" monocycle is just too susceptible to gerbiling. What would we call the equivalent failure mode for the RIOTwheel -- "fly swatting"??! :> (I've got faint traces of an old cartoon that comes into mind when I think about that failure... I'll have to see if I can recall who/what cartoon character was involved!)
Of course, for the treadway it's "canyon flopping"...
(Perhaps the unicycle is the "safest"?? Though the idea of sitting on a post doesn't strike me as terribly reassuring!)
Hang glider always seemed like the most appealing form of solo flight, to me. Of course, it tends to rely on having large differences in elevation available... (i.e., controlled falling vs. "flight")
Well, I wouldn't be keen on dying due to an engineering screwup! Especially if it was foreseeable!
Yes. Travels *along* the ground (instead of through the air).
It's essentially a copy of Helvetica, with small differences.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
On a sunny day (18 May 2012 23:30:38 GMT) it happened Jasen Betts wrote in :
Not in my (not so humble) opinion. Compared to the other fonts installed 'by default' arial looks very nice. Most of the rest I have only one word for: shit.
There is a REASON it is so common, and it is not because it starts with 'A'
Some people like dingbats it seems, it comes with MS windows too? Lets rename it adingbats, what do you think?
There may be something to that. I think it is also the default of MSwin/MSoffice. Lousy unreadable piece of shit font. I always set my system and office fonts to something serif. Courier for fixed spacing. Much more readable.
I think it's common because Microsoft wanted to avoid paying license fees to the owners of Helvetica, so they used a knock-off that just happens to look almost identical to non-specialists. It's almost Grotesque. Apple, OTOH, did license the genuine Helvetica font. Most graphics professionals seem to prefer Helvetica, but of course Windows is ubiquitous.
Zapf Dingbats is a good dingbat font. Hermann Zapf also designed Palatino, a remarkably beautiful font. I also like Adobe Caslon, which is used for the body text in both the _New Yorker_ and _Foreign Affairs_.
On Helvetica v. Arial.
formatting link
A quiz to tell Helvetica from Arial
formatting link
See the feature length film "Helvetica"
formatting link
.. and remember, Papyrus is the new Comic Sans.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Generally speaking, I think a serif font is better for body text, and a sans-serif makes a nice contrast for headlines.
formatting link
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
[Drifting even further off-topic but...] I wish Foreign Affairs was less rigid in their use of small caps for acronyms (i.e. EU, NATO). It may be "proper" (at least as prescribed by Bringhurst) but it just looks strange, almost as bad as if they started using the "long s" again.
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Exactly. Sans serif and decorative fonts are best used sparingly. The eyes seem to need the serifs lest they "slip off" the glyphs.
This also provides a visual cue to the reader as to the significance of what he is reading and where it sits in the document's hierarchy of structure. E.g., pick a san serif typeface for your "heading font" and then scale it to convey different levels of headings. (whatever you do, *don't* pick different typefaces for each level of heading as it just becomes visually confusing and looks amateurish -- like trying to use EVERY crayon in your "crayola 64 pack")
I use a fixed width serif font (e.g., courier-ish) for my "computer text" (i.e., code fragments in documents) and, within that, rely on small caps for lowercase portions of any text. This gave me a balance between upper+lower as is common for modern HLL programming and "all caps" as was common for *ancient* ASM listings.
It's surprisingly easy to get used to -- but, when it is not the emphasis of the publication; rather, sprinkled throughout it (it also very dramatically sets it off against the body text).
Early on, I adopted the habit of using color as an aid (to me) in further differentiating types of text (think SGML) within a document. For example, "computer text" is typeset in blue. Originally, I did this to help me verify (quickly) that I had applied the correct styles/tags to each bit of text in a document (e.g., wherever "strlen()" appears, it is set as computer text *even* if in the body of the document -- i.e., NOT just when appearing in a "program fragment"). I didn't intend my documents for public consumption so the reliance on color (normally something to be frowned upon as a means of conveying information) was acceptable. I have since found that it actually helps me read documents as it lets me quickly find the issues likely being addressed in the text body just by looking for these splotches of color. (i.e., try finding "NL" in a large patch of text when the only thing setting it apart visually is "courier" vs. "palatino")
[when writing SGML, it's significantly more important that you get the tags right compared to "applying the right typeface/style, visually"]
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.