rawles / edit.tf

An in-browser editor for teletext frames.
http://edit.tf/
GNU General Public License v3.0
92 stars 19 forks source link

An indicator of whether the frame is 'broadcast compatible' #62

Open rawles opened 7 years ago

rawles commented 7 years ago

As frames find their way to places like Teefax, we would like to encourage designers to keep rows 0 and 24 free for broadcast systems to replace the header and insert Fastext links. At the moment the editor does nothing to do this besides the grid (Esc-X).

@peterkvt80 suggested a flag warning when a frame is not 100% broadcast compliant. Let's put this in the status bar. Initially I think we could make this three colours, like a traffic light.

Red: You are using row 0, which will be overwritten by an inserter. Yellow: You are using row 24, which will be overwritten by Fastext links. We could also use this to mean 'you are using foreground black', but that's totally normal and usual on the teletext services of other countries. Green: Rows 0 and 24 are free (and maybe, foreground back hasn't been used), everything is groovy.

Does this seem sensible to everyone?

[Paging @ZXGuesser and @pjfdirect who knows about these things too]

pjfdirect commented 7 years ago

Sounds good to me.

I have a 'teleletext design' post in the works sharing my design goodies with Dan and the general public, plus links to editors and such - I'm happy to echo those guidelines.

Some who read it might be Teefax bound but others might just be footloose pixel artists or doing 'not necessarily teletext' things like Alexi Sayle's thing below so it may fast track them into the distinctions.

ceefax by sayle

rawles commented 7 years ago

Great, we can add that to the list of resources for people starting out, alongside the how-to guide and stuff like that.

What are your opinions on whether foreground black should be considered a 'yellow light'?

ZXGuesser commented 7 years ago

Sounds sensible. I don't have much to add besides that when it comes to leaving Row 24 free, that row is not used in systems that use Table Of Pages navigation instead of FLOF (fasttext). Where fasttext is in use it's more a case of the fast text links being an decision made by the person running the service rather than the author of a particular page - or they may be the same person.

Reminding people that row 24 should only be used for the prompts for fasttext links is a good idea though. While you can ignore the FLOF code of practice and put anything there the spec does warn that it's not advisable to allow enhancement objects to spread into row 24 because some decoders display row 24 below row 11 when in "page expansion" mode (i.e. zoomed). Though it doesn't mention this in regard to using row 24 for things other than in conformity with the FLOF code of practice I would think the same argument applies against putting general content on that row too.

ZXGuesser commented 7 years ago

Another thought is that the distinctions of row 0 and row 24 being "special" in teletext is irrelevant entirely if you are using edit.tf to design Mode 7 artwork for a BBC microcomputer.

rawles commented 7 years ago

Thanks for all the very detailed information! Definitely a good point about the BBC micro stuff. By the way, the editor doesn't implement BBC Micro display properly, e.g. how the top and bottom of a double height line can be, for example, different colours. Anyway, this is why I like Peter's suggestion - a little flag or traffic light is subtle, and can be ignored if the designer isn't making a teletext frame. Likewise a subtle box that can be turned off.

peterkvt80 commented 7 years ago

I don't think that foreground black is that bad a thing as everything should support it these days. What would be interesting would be a "Level" indicator which is set to the level of the highest feature used. So for the purists, a page within the original IBA spec. would be 1.0. Black foreground would be 2.5 etc.

rawles commented 7 years ago

I've just added this and merged it in - there is a little traffic light on the bottom right of the screen. By default, there are subtle grid lines showing the teletext area. Have a look - do you think it's ok but a bit much?

rawles commented 7 years ago

The grid also disappears temporarily when the status bar is hidden (bug #61)

rawles commented 7 years ago

A case which this doesn't cover, but which would be easy to detect: if row 23 has double height characters on it, then teletext receivers will render those characters in row 24. Does that turn our light yellow? I'd say probably yes.

rawles commented 7 years ago

The light also goes bright red if any of the first eight characters are non-blank! :)

ZXGuesser commented 7 years ago

I would say it should go red. As per the notes on double height and size in Table 26 of The Spec my editor forbids setting double size in rows 23 or 24 (and strips them on import). The same for row zero but that is stripped entirely anyway in my case.

peterkvt80 commented 7 years ago

Funny you should mention double height in row zero. wxTED and my TV supports that.

ZXGuesser commented 7 years ago

Well the specification doesn't seem to say anywhere that decoders shouldn't accept it, only that broadcasters shouldn't transmit it 😄

"If a decoder receives an illegal combination, it may chose, for example, to display a partial character, to reduce the size or to ignore the character completely."

irrelevantdotcom commented 7 years ago

Here's another frame size limitation - . Prestel imposed a limit of 920 characters per frame, including at least 44 for line 1. Control codes took up 2 each. Lines were terminated by CRLF (unless they were already 39/40 characters wide!) so could be less than 40 characters. This did mean that if you do complicated full-screen graphics you could easilly run out of characters to do them in! It did encourage some extra creativity... (judicious use of double-height when you might otherwise not have thought to use it could save an entire line of data!)

Probably not an issue for any applications these days - most file formats I have come across store a straight 22 or 23x40 image array, but it's something that sprung to mind!