movingforward

From twext

Jump to: navigation, search

Contents

[edit] Moving Forward

[edit] quick plan

[edit] 080630 target date

ok dust settled, face time good, thanks jason.. now we have a two week parameter so you can work independently toward:

  1. pdf printing
  2. from simplest dod0
  3. and get to know old code

working independently, gabriel can focus on http://b.twext.com/simplest in php without distraction.. by end of june let's see what we all have then coordinate

[edit] work

a pdf twext machine is very practical: i can use it in class immediately, thanks.. dodo is good for me because i can organize TEXTtwxt sources for simple testing on local machine.. (later, variable db can suck dodo:) great..

i'll make a fake roadmap for you that you will fix.. then we make deal so you be happy

[edit] responsive

respond to my testing feedback quickly is good.. i get frustrated if my feedback hangs unanswered for several days.. good communication will help us live long and prosper, thanks (looks like no problem:)

[edit] play

if curious, get oriented with existing system and code:

[edit] last week

[edit] Core Library Issues

1. Double chunking errors. The word chunker needs to handle double chucking errors correctly. The chunker needs to work. My idea here is to first filter the list of words to make sure there are no duplicate in (before, after, both).

Then to run "both" list first. Then apply the Before and After list on words that do not already have a New Line in those positions. I think that should solve most of the double chucking problem.

Also line width should just be a part of every chunker. I think it would be a pretty useful thing just to have it available in all chunkers.

20 peso breakfast face time is needed.. as i understand it, chunker chunks text, twexter then formats text.. if ParagraphText, then twexter formats for variable display width.. so why save line breaks with chunks?
easiest simplest first step is lyric chunker.. narrow focus to lyrics and we get delyric twexter.. high value, lower cost.. if you wanna tackle complexity of twext line breaks now and can deliver on roadmap, i don't wanna stop you.. you have freedom for this trial month until 10 july to prove you can manage this project and deliver results.. my job is to shut up and listen ja ja..

This is not complex... Also one chunker should handle most requirments. You free to set any time limit you wish. I don't have much to prove to anybody.

duke: no prob, but we need targets for to make good deal no?

I just want to get the chunker to work correctly. I am only wotking with the english work chunker and the line width chunker now.. If that handles lyrics or not.. Not sure. But they both can double chunk. Needs not to happen.

Forgot to mention in my word chunker. I have add two extra filters. That is the "Before Symbol" and "After Symbol". The reason is normally you are looking for whole words in the filter. Symbols are not words and the current code didn't work with them at all. I wanted to add a new line after a period.

new line after period requires exceptions ie dr. mrs.

Good point, noted

I think that was important. So I could have maybe made the filter a little bit smarter and look for symbols in the words list. But personally I liked having the symbols separate. Just keeps the code simpler to understand. Though in the Gui these can be added back into the word list.

2. Manual/Automatic Line Breaks. Line break symbols need to be added into the twext tree (a spec on JavaScript format?). Exporters need to be able to handle these special line breaks. This is so we can handle some layout requirements.

now i'm not sure.. hopefully you have a great solution i can't imagine until i see

3. Html code and styles need to be reviewed to see if it is possible to fix a small little bug in IE. Sometimes in IE a chunk in the new exporter code (Jason) can wrap inside itself. Because IE will shrink the width of the chunk to fit in the last position. This does not destroy the document but can be an annoyance.

you are prepping us for IE testing (50%+ of target testers are translators using IE). yes.

One idea is to use a JavaScript method to measure text width and force each chunk to that width.. Or see if there are some style sheet rules to handle that. I am not a HTML guru so somebody might have a better idea. Otherwise to get perfect alignment...

problem might snag us, if we simplify to just lyric boxing (framing) then maybe simpler.. again, i've tried to simplify before and look where it got me.. ja ja.. you are the boss now

well, I not looking to simplify.. it is realy a small little bug in only IE. I am sure there is a good fix for it. The way I envision it is ti workds in a frame or not.. really doesn't matter to me. it works within a html container now. Of course maybe I am missing somthing. But it is really simple right now. just needs tweaking. I only spent a 30 minutes on it and got IE to work pretty good. so we will see what a few more hours can do.

4. (Opcional) if html layout becomes something to difficult to handle. A JavaScript chunk placement engine might be needed. But if we have to create a good text layout solution we might as well just use flash or some other technology where this can be done perfectly every time. I personaly would like to stick with HTML and JavaScript for now.

ultimately another key target is flex or flash http://synxi.com animated (timed text) of twext.. could be easy since we already manage chunks (eg filename chunk TEXT line 33 TIMED one second) plenty of whoopass waiting to do but first simplest twexter like you want..

I am a flex fan my self. Personally I think it too much for just a simple text layout.. even with animation. I would probably program that directly in flash (which flex really is just fash, with the same libraries and everything. just focused on creating user application)

 :)

[edit] Data and Printing

1. I think before we get into modifying or creating another GUI. Ja Ja Ja. How we save data and how we are going to make printing available should be addressed first.

yes, sir
printing in pdf is high value target: imo, it would be really helpful if we focus on this, so i can show the tool working in my classroom

2. Data still probably needs to be talked about. I want to have a very open way of storing and retrieving documents. Where the data layer is a plugin. I going to push for the main plugin to use a database.

agreed, database is the smart start, db can later spit out twexml which can then be dodo'd if need be.. please move forward with database.. sqlite?

Dodo is a great format for saving locally or sending by email.

dodo more wants to be wild format for small personal individual data sets in human readable order.. if used, then 1) variable databasi can suck dodo (ie restrict to language.pair, author.translator, wheteva.etc) from the wild and 2) users can FIND *.dodo or *.twexml or *.twx in the wild via search

But just not a great way to save data on the server. Managing just 100's of file and indexing them and keeping them corruption free is way more work then I want to do just to save some twexts. Duke is against it

i'm for it: db > xml > dodo

but really a database offers alot of free functionality I personally would like to take advantage of. Open for discussion but must be done before returning to the interface. The current way of saving is unacceptable, its great as a prototype and fun idea, just not practical at all.

ok

[edit] PREVIEW PRINT PDF

3. I have developed a php script which writes twext chunks to PDF quite well.

great new, this leads to very important tool: , which combines both SIMPLE and LYRIC chunk boxing..

I hope to extend that quickly to something basic for version 1 of the twext user interface. This is will have just the necessary functionality to start out with.. The objective here is just get printing and data ready for the application.


4. (optional) Users... some users probably are going to want to share some of there twext and keep some private. There is alot of good stuff for if you have users. One, it should not be enforced, everyone can use twext. If you want the extra functionality you can sign up. I believe eventually this is just necessary but not required right now.

yes, preferences etc, not immediately but immediately next.. ultimately twexter wantsa learn what words you use and how, but now we just need a useful tool..

But all saving would be public and finding your personal documents when you don't have an identity is not that easy or practical.

dev was aiming toward django.. you mentioned gears..

Django is a python frame work for building websites. We are just creating a simple tool. of course somthing like django would be cool for a large appliction and website. I think we have been delayed enough. Using django just adds another layer of complexity to the project.

i really love the idea of a roadmap that has very narrow, achievable targets.. it is a high priority to show this tool working in the field, like in my classroom.. can we consider scaling back and focusing simple?

Another road to take is google gears, so users can save on there local computer. But, looking at the future possibilities I think that is just a bad idea right now. Google gears would be a great tool to let users use the tool while offline... but thats for another discussion.

jason is the boss and tudisco is cool.

[edit] Yippie! GUI TIME

1. Once we have addressed those issues... Then I believe we are ready for a GUI tool. Starting with a basic tool that can chunk text. give you two columns to edit with.. Set some basic styling settings. Then Save and Print. Let people use it before implementing new features. Public input is always full of surprises.

cuando crees mas o menos?

This section will probably be edited latter to define the exact features. The idea here will be to have as many features as possible but keeping it as simple as possible as well. Any complex features at this time will simply be ignored until we have the basics working well and across browsers.

only complexity i forsee is text chunk box frame format variable line breaks.. restrict to lyrics maybe simpler (it's only a suggestion for simpler start)

I not sure why you believe lyric chunker would be simpler then text chunker or simple chunker.

chunker inserts orderly returns ala method.. but chunker may need different rules for lyrics.. later we can accurately interpret a text to say whether it is LyricText or ParagraphText.. then either type of text is boxed or framed so it can be translated and formated and styled twext


to chunk ParagraphText, chunker interprets periods, ".", minus the mrs. dr. etc. exceptions, as end of sentences so chunker adds two returns (and corrects BEFO and BOTH double (triple) chunking errors.. and when boxing ParagraphText, we often need to break TEXTtwxt chunks with twext line breaks
to chunk LyricText, chunker just needs to find returns and end of each line and adds a return (no exceptions necessary).. we still need to correct double (and fewer triple) chunk errors.. but no twext line breaks needed..

Jason Says- Ok i think this is supposed to be about the editor part of the chunker.. Variable line breaks.. Hum bug I say! editing issues are for gui designer. I want to be the core guy.. to me, core should not care.. this needs a meeting. Ignore text below for now.

i'm open tomorrow monday after 11 before 6

But I am working on the chunker provided to me.. which was a word chunker using enlgish words. I have added line width. The text I generate flows inside any frame. Thats to me is as simple as it gets. But I might just have to read you formats again to try to understand better why. Curretly what you see on my test pages is what is working.. I can only tell it has alot of improvments from code I recieved. I just work on making that better. I´m sure there are more complex chunkers ideas. I not interested right now. Chunkers are plugins... so after were creating documents people can design all kinds of chunkers. But, with the special line breaks I think that will make up for anything thats not automatic when generating the document. But the more I get into it, The more opinions I will have. But to make it clear, I working with a code rewrite of the origanal code. Which has a chunker based on words that had many double chunking errors. So that is what I am working with. As far as text generation you seen it flow within a frame in my example. Biggest problem now is I can't force a line break, which just is necesary for lyrics and text layout in general.
what I working toward is getting a working example of the example you have online.. jajaja. Just get people using it. Let them drive improvments through feedback. Also when were enjoying that we can plan for bigger and better things.

[edit] roadmap

above is lovely.. the question is: when? or by when? (more or less)..

Will have a better idea on when, when I can figure out what. meeting time. I would not set a date before then. It could be a week before we reach warp speed. Warp core has a melt down... Its in repair mode.

ok so week 1: big splash, week 2: prep, week 3: warp, week 4: a billion users
roadmap needs new plan.. doh.. starting this week (done), what can we do this month? what steps?
meeting milestones, actually delivering before milestone is very helpful.. this will change the whole vibe coming from twexter's dark cursed past.. establish new practice of whoopass solutions delivered on time i know this is hard with software, but clear simple well defined problems with well padded cushy compfy target delivery dates might make it easier..

this is easier to accuplish by making smaller milstones. the smaller the better. this way people don't get overwhemled. things look simple. Also if one milesone goes bad... it is always important to refactor right away.

sounds great, let's see

Yep, I break milestones all the time.. jajaja.. for like implementing software on 50 servers.. or making a web applications communicate with desktop accounting software. there is no reason why this project has to be that way.. it is small enough to manage and meet most milestones I believe. Until it gets big of course. Hahaha. By that time you'll be much happier and so we will be able to get away with alot more ;) .. haha.
Retrieved from "http://twext.com/movingforward"
Personal tools