Thursday 13 December 2012
MS Office trouble
Problem
-------------
Users having:
- Office 2003 (sp3) with Office 2007 compatibility pack (sp1).
- Office 2007 (sp1)
work on the same document on a smb share.
From on point in time, the user using Office 2003 gets:
"Filename.ppt is currently in use. PowerPoint can't modify it at this time."
when he tries to save it (even if no modifications done).
Cause
---------
The user with Office 2003 has inserted some excel tables as embeded (instead of graphic). This article appears to apply: http://support.microsoft.com/kb/285517
Solution
-------------
Using Office 2003 , copy/paste all slides to a new powerpoint and save it as Office 2003. Then replace the pptx with this one and instruct the users to use this ppt instead (and save it as ppt no matter if they use 2007/2010).
Sunday 2 December 2012
The perfect laptop backpack...
... has not been created yet.
The "almost perfect" laptop backpack was my last Targus. But somehow they decided to discontinue it and trash its features instead of just adding some new ones on.
This is a list of features I would love to have at my laptop backpack and cannot find them all at any on the market, so far. Backpack manufacturers, erm... take notes?
God bless your back(pack)!
The "almost perfect" laptop backpack was my last Targus. But somehow they decided to discontinue it and trash its features instead of just adding some new ones on.
This is a list of features I would love to have at my laptop backpack and cannot find them all at any on the market, so far. Backpack manufacturers, erm... take notes?
- Secret pocket. My old Targus had one hiden in the lower back padding. Super super feature! Even I needed few month to find it :)
- Cell/Mobile pocket on one of the brackets. You need to visually check you mobile to decide if you answer/call back/etc, right? Then why putting the mobile somewhere inside, where you cannot reach it it unless you take off the backpack? Old Targus had it.
- Side pocket keychain. It's super to be able to reach the keys without taking off the backpack. Targus had it but I needed some practice to be able to reach and get the keys off the chain; still I managed to do it.
- Outside bottom made of special fabric / plastic / lether / rubber. Targus had it made of a kind of plastic fabric and I didn't care if I put it down in muddy or wet areas because it was easy to wipe afterwards and completely water proof.
- Laptop compartment access from the side. I would prefer to be able to take out/in the laptop without opening the round upper part zipper of the backpack. It would be much easier to be able to extract it through a side linear zipper (only the laptop not the charger, etc). This is the only feature missing from my old Targus but at the time I bought it was not "invented". Now I can see some models on the market having this nice feature.
- Some obvious and very common features: External side pocket for bottles (even one on each side). Padded back, straps, and laptop compartment. Diveded interiors with various mesh/non mesh pockets and zippers. Most of the backpacks have these anyway.
God bless your back(pack)!
Monday 15 October 2012
Modern Perl and the lack of "great" programmers
I'd like to collect some opinions about the following things. I am
referring to some of the recent posts on linked-in, about recruitment
and the lack of "great programmers".
A bit of history in my (possible distorted) view:
When OO appeared there were debates on the fact that has certain disadvantages over procedural like speed and being more verbose (over the advantages of allowing abstraction and allegedly being better for organizing huge code).
Then, in Perl's world, there were voices saying that one should not bother to learn OO perl because it is not a real OO, it is more a set of cumbersome conventions than a proper OO implementation.
Finally Moose appeared and practically defined a sub-language, a lot of "sugar" to overcome the base language OO limitations.
Now everybody jumped happily in Moose's boat and no-one talks about procedural Perl and, more important, they don't accept anymore procedural at interviews.
Like OO Perl is more than just another way to structure Perl code.
I call "There Is More Than One Way To Do It" in my support. True, I read somewhere: "Because TIMTOWTDI, don't assume that you can do it any way you want" but I tend to disagree for most of the situations.
In my opinion, the main purpose of any application is to meet the specs and also to be done in the allocated time. If you think of the application as a black box, and you managed to make it work as expected and tested it thoroughly from any angle, I really don't understand why would anyone would care *how* it is inside the black box. Is like, you can hit a nail with a hammer or with a pair of pliers and to a certain extent the outcome will be the same, depending of the wood's resistance.
Of course, when it is about interacting in a team and if there is a defined programming style, the applicant should converge to it, to respect the house rules. Still, it doesn't mean that procedural Perl should be a reason to reject a candidate at technical interview time.
It seems that only few companies are still willing to allow time for learning and they all ask for guys that can "hit the ground running" (again, mind you, we talk about a style not about core programming skills). But no one can know everything needed at the new job already. If (s)he knows everything, there is a chance (s)he might be tempted to look somewhere else for a challenge.
I think that's why a lot of recruiters/companies complain about the fact there are not many "great" programmers on the market. (BTW: Define "great". How? By compiling a list of technical questions that all "great" programmers should know? This might be a wrong approach. See http://it-quirks.blogspot.com/2012/10/modern-perl-recruitment-contd.html).
I bet there are lots of good Perl programmers but they get rejected (and possibly going to other languages) because they were considered as not fitting the target company's programming style. The companies are incredible picky these days about the style, and the middle layer (agents) is escalating this much more by not knowing what's really about.
And then the advertised job stays on the market for 6 months or more and the agents and companies, at unison, lament about the fact that "great" perl guys are a scarce resource. Maybe giving a chance to any Perl programmer that can do the application no matter the style, would be more beneficial for the company. Put in balance the 6 month fishing for the "great" programmer versus few month a "regular" guy can learn the new environment's specifics, style, etc.
Maybe it is time to admit that we're not so many out there, therefore you need to be more flexible. Otherwise, wait.
I'm not trying to diminish the importance and role of OO Perl or Moose. I would just love that the recruitment wouldn't be so exclusive about it nowadays, because things can be still done very well and fast, the procedural way. Besides I don't think that it'd take more than few weeks for someone to adjust from procedural to OO style of the company. Not to mention that OO design sometime is a separate job in many companies, and in the end the programmer ends up writing code inside the same class, not needing to know the big OO picture.
So, how hard you think it is for an "regular" perl programmer to switch from procedural programming to Moose?
A bit of history in my (possible distorted) view:
When OO appeared there were debates on the fact that has certain disadvantages over procedural like speed and being more verbose (over the advantages of allowing abstraction and allegedly being better for organizing huge code).
Then, in Perl's world, there were voices saying that one should not bother to learn OO perl because it is not a real OO, it is more a set of cumbersome conventions than a proper OO implementation.
Finally Moose appeared and practically defined a sub-language, a lot of "sugar" to overcome the base language OO limitations.
Now everybody jumped happily in Moose's boat and no-one talks about procedural Perl and, more important, they don't accept anymore procedural at interviews.
Like OO Perl is more than just another way to structure Perl code.
I call "There Is More Than One Way To Do It" in my support. True, I read somewhere: "Because TIMTOWTDI, don't assume that you can do it any way you want" but I tend to disagree for most of the situations.
In my opinion, the main purpose of any application is to meet the specs and also to be done in the allocated time. If you think of the application as a black box, and you managed to make it work as expected and tested it thoroughly from any angle, I really don't understand why would anyone would care *how* it is inside the black box. Is like, you can hit a nail with a hammer or with a pair of pliers and to a certain extent the outcome will be the same, depending of the wood's resistance.
Of course, when it is about interacting in a team and if there is a defined programming style, the applicant should converge to it, to respect the house rules. Still, it doesn't mean that procedural Perl should be a reason to reject a candidate at technical interview time.
It seems that only few companies are still willing to allow time for learning and they all ask for guys that can "hit the ground running" (again, mind you, we talk about a style not about core programming skills). But no one can know everything needed at the new job already. If (s)he knows everything, there is a chance (s)he might be tempted to look somewhere else for a challenge.
I think that's why a lot of recruiters/companies complain about the fact there are not many "great" programmers on the market. (BTW: Define "great". How? By compiling a list of technical questions that all "great" programmers should know? This might be a wrong approach. See http://it-quirks.blogspot.com/2012/10/modern-perl-recruitment-contd.html).
I bet there are lots of good Perl programmers but they get rejected (and possibly going to other languages) because they were considered as not fitting the target company's programming style. The companies are incredible picky these days about the style, and the middle layer (agents) is escalating this much more by not knowing what's really about.
And then the advertised job stays on the market for 6 months or more and the agents and companies, at unison, lament about the fact that "great" perl guys are a scarce resource. Maybe giving a chance to any Perl programmer that can do the application no matter the style, would be more beneficial for the company. Put in balance the 6 month fishing for the "great" programmer versus few month a "regular" guy can learn the new environment's specifics, style, etc.
Maybe it is time to admit that we're not so many out there, therefore you need to be more flexible. Otherwise, wait.
I'm not trying to diminish the importance and role of OO Perl or Moose. I would just love that the recruitment wouldn't be so exclusive about it nowadays, because things can be still done very well and fast, the procedural way. Besides I don't think that it'd take more than few weeks for someone to adjust from procedural to OO style of the company. Not to mention that OO design sometime is a separate job in many companies, and in the end the programmer ends up writing code inside the same class, not needing to know the big OO picture.
So, how hard you think it is for an "regular" perl programmer to switch from procedural programming to Moose?
Sunday 14 October 2012
Modern Perl recruitment - cont'd
This is in response to some recent posts on linked-in, some of them leading to http://www.modernperlbooks.com/mt/2011/01/how-to-identify-a-good-perl-programmer.html
I think compiling a list of questions for the recruiters to ask for when filtering candidates is wrong and irrelevant for few reasons:
First of all, the weight of each question in the list should be judged in the context of the particular job requirements. No-one knows everything about Perl (maybe with few exceptions, see below the "top N").
Then, the weights of two questions could appear comparable to the recruiter and the candidate could get rejected based on wrong assumptions. Take these 2 examples from the list:
"What's the difference between == and eq?"
-- versus --
"Where do tests go in a standard CPAN distribution?"
One one side, if a programmer doesn't know the difference between == and eq, then we might have a problem (still debatable if the guy is coming from lots of years experience in PHP for example).
On the other side even an experienced programmer might have never been in the situation to care about the tests in the cpan distributions: if everything installs correctly and never created a CPAN module, why should one bother?
You can find more pairs of "extremes" in the list to prove this point.
The list also proved its limitations as a lot of people on linked-in already started to ask for clarifications. Assuming that someone really fixes the list's "bugs" as feedback is received, discussed and changes agreed on, probably endless iterations will be needed.
As for the relevance of asking somebody these questions, as the present list's answers can be found in only one book (Modern Perl), if anyone really wants to fool the examiner can do it by just reading this quite small book. Even easier, any perl wannabe can find now the list on the internet and can prepare the answers for potential future interviews.
Finally, knowing everything about perl is quite impossible: everyone has strong areas and weak areas and the capacity (or lack of) to improve in the weak ones if the job requires it.
Not everybody is Larry, Damian or Randal (and the list might continue to a top N). On the other hand not every company would need (or afford) any names from this shortlist. Bothering one of the top N programmers to write scripts for a company that sells ladies bras, briefs and stocks would seem a bit out of proportion, much like using a hammer to kill a mosquito.
I think compiling a list of questions for the recruiters to ask for when filtering candidates is wrong and irrelevant for few reasons:
First of all, the weight of each question in the list should be judged in the context of the particular job requirements. No-one knows everything about Perl (maybe with few exceptions, see below the "top N").
Then, the weights of two questions could appear comparable to the recruiter and the candidate could get rejected based on wrong assumptions. Take these 2 examples from the list:
"What's the difference between == and eq?"
-- versus --
"Where do tests go in a standard CPAN distribution?"
One one side, if a programmer doesn't know the difference between == and eq, then we might have a problem (still debatable if the guy is coming from lots of years experience in PHP for example).
On the other side even an experienced programmer might have never been in the situation to care about the tests in the cpan distributions: if everything installs correctly and never created a CPAN module, why should one bother?
You can find more pairs of "extremes" in the list to prove this point.
The list also proved its limitations as a lot of people on linked-in already started to ask for clarifications. Assuming that someone really fixes the list's "bugs" as feedback is received, discussed and changes agreed on, probably endless iterations will be needed.
As for the relevance of asking somebody these questions, as the present list's answers can be found in only one book (Modern Perl), if anyone really wants to fool the examiner can do it by just reading this quite small book. Even easier, any perl wannabe can find now the list on the internet and can prepare the answers for potential future interviews.
Finally, knowing everything about perl is quite impossible: everyone has strong areas and weak areas and the capacity (or lack of) to improve in the weak ones if the job requires it.
Not everybody is Larry, Damian or Randal (and the list might continue to a top N). On the other hand not every company would need (or afford) any names from this shortlist. Bothering one of the top N programmers to write scripts for a company that sells ladies bras, briefs and stocks would seem a bit out of proportion, much like using a hammer to kill a mosquito.
Wednesday 10 October 2012
Modern Perl recruitment
I am currently looking for a job using good old Perl and things seem more annoying than ever before. The frustration came back gradually, and most of it comes from the middle layer: the recruitment agents.
Let me start by clearly stating that not all the agents are the same and not all of them are "bad". However, unfortunately, many fit the description below.
This special breed of people, the perfect salesmen (in their views), is interposing between me and my "happiness" in annoying ways. Here are some things they, and only they, know how to do best:
Unfortunately there are so many companies that act the same through their HR department.
I have a real example, one that is these days on the jobs.perl.org: Heart Internet, UK. They think is ok to cut all communication with me, *after* I spent few good hours on their programming test. I don't care if my solution was dumb or not to their liking, I just consider I am entitled to an answer, at least as a sign of courtesy after wasting my time.
This job based in Nottingham is present on jobsite.co.uk also cloaked by an agent: Simon Harris, Applause IT (see above about cloaking).
Same communication skills from this guy too. I sent them together about 10 emails until now asking for feedback, no reply.
Say, what about a database with agent names and star rating/feedback? Something similar to yelp.com but focused on recruitment agents/companies.
Also, it could be extended for any job recruitment agent, not only for Perl.Anyone?
Let me start by clearly stating that not all the agents are the same and not all of them are "bad". However, unfortunately, many fit the description below.
This special breed of people, the perfect salesmen (in their views), is interposing between me and my "happiness" in annoying ways. Here are some things they, and only they, know how to do best:
- They understand 50% (if...) of what you can really do, but they have the audacity to decide your professional life by not putting you forward to the decision maker, the one that would really understand (as he needs and asked for you skills).
Sometimes you don't check a skill and, even they don't know what's the real relevance of it or how easy it is to learn it; they just feel that skill sounds impressive. If you don't have it, you're a looser.
Some other times they don't like you, you'll never know why. - They publish their own, "cloaked" version of a job that's already published directly by the hiring company. They leave the same keywords inside 'cause they're unable to reformulate the skill set.
- They publish non-existent jobs, probably just to motivate their existence to their bosses by pretending they have activity. Moreover, they fish for leads by asking you to provide info about any other interviews you had, motivating that they don't wanna overlap with other agents on the same positions.
I am sure (!) they don't contact an employer if they know that some other agent is already there :) They do have an exaggerated common sense. - They treat us as like... cattle by adding quantities to the job titles, like: "50 perl developers for a big company[...]", "Calling for all perl developers [...]".
We should just moo-in by sending all resumes to them. It's kinda depersonalizing, you know? What about having a regular posting for the job and selecting how many people you needed, afterward? - All the companies they're recruiting for are presented as they are the latest shit on the market, next to Oracle or Microsoft or whatever you consider it's a big shit these days (pun intended :)
Buzzwords include: "thriving environment", "exciting", "world leading", "voted as number one expanding", "global footprint", etc.
Have you thought that I just might prefer a regular sized company that would have obviously many advantages over the corporate, impersonal ones?
- You need to be psychologically abnormally addicted to work to please them. I mean, why would anyone choose to "dream in LAMP", "eat and breathe Perl", have an "Unquenchable thirst to automate mundane tasks" or be a "Perl junkie" instead of being a regular work-life balanced individual?
Unfortunately there are so many companies that act the same through their HR department.
I have a real example, one that is these days on the jobs.perl.org: Heart Internet, UK. They think is ok to cut all communication with me, *after* I spent few good hours on their programming test. I don't care if my solution was dumb or not to their liking, I just consider I am entitled to an answer, at least as a sign of courtesy after wasting my time.
This job based in Nottingham is present on jobsite.co.uk also cloaked by an agent: Simon Harris, Applause IT (see above about cloaking).
Same communication skills from this guy too. I sent them together about 10 emails until now asking for feedback, no reply.
Say, what about a database with agent names and star rating/feedback? Something similar to yelp.com but focused on recruitment agents/companies.
Also, it could be extended for any job recruitment agent, not only for Perl.Anyone?
Wednesday 21 March 2012
Microsoft has solid software... literally!
One of the companies I had in my care started to think that maybe they should invest some money in M$ licenses, that their world will be simpler after, so they called M$ specialists to convince them.
We are talking about an NGO with 6 people from which only 3 are involved in projects and only one is a spare time project manager. They all had Office 2003 at the time.
It was an "interesting" experience, to see the M$ ties coming and trying their regular marketing bullshit about "productivity", "seamless integration" and alike, on my managers.
They planned for me to upgrade my server, that has the only role of hosting one share to the users. They wanted to replace my Debian + Samba, with their Windows 2008 server and a Project Management server on top of it that goes well with all the Office 2010 installations.
Are you kidding me? For 6 users in an NGO that has nothing to do with big projects?
Well, they did succeed renting one year Office 2010 to my users; they got sick of it and discover there is no real benefit for them, only lost money. The new servers implementation was left for stage two and thanks God it never happened, as my users actually ended the leasing contract
Few weeks after ending the contract, we got this letter from Microsoft asking us to destroy the CDs and DVDs and sign a form that we did!
This made me think how can I comply better with their legitimate request, and here is what I come up with:
http://www.youtube.com/watch?v=GNAF2bvkjcg
We are talking about an NGO with 6 people from which only 3 are involved in projects and only one is a spare time project manager. They all had Office 2003 at the time.
It was an "interesting" experience, to see the M$ ties coming and trying their regular marketing bullshit about "productivity", "seamless integration" and alike, on my managers.
They planned for me to upgrade my server, that has the only role of hosting one share to the users. They wanted to replace my Debian + Samba, with their Windows 2008 server and a Project Management server on top of it that goes well with all the Office 2010 installations.
Are you kidding me? For 6 users in an NGO that has nothing to do with big projects?
Well, they did succeed renting one year Office 2010 to my users; they got sick of it and discover there is no real benefit for them, only lost money. The new servers implementation was left for stage two and thanks God it never happened, as my users actually ended the leasing contract
Few weeks after ending the contract, we got this letter from Microsoft asking us to destroy the CDs and DVDs and sign a form that we did!
This made me think how can I comply better with their legitimate request, and here is what I come up with:
http://www.youtube.com/watch?v=GNAF2bvkjcg
Create a movie for youtube on Ubuntu - tutorial
Prerequisites:
- You're on Ubuntu or similar linux.
- You need to create a movie (e.g. for youtube) and you have:
-- some avis from your camera, (some should be 90degrees rotated as they have been filmed wrong)
-- jpegs from you computer (or screen captures)
-- a mp3 track to add on some parts of it (slideshow like)
- You need to add subtitles and some fading effects.
How I did it
- I decided to have the resulting film in m-jpeg video codec format and AC3 audio codec. I had 640x480 30fps avis from my camera, audio: mono, 8KHz. Your data might differ, what's important is to have all parts with the same parameteres before joining them together.
- To cut the interesting parts from your .avi you can use Avidemux and in this operation you can convert them to m-jpeg/ac3 format.
- To rotate the movie you can use avidemux -> video filters -> Transform -> Rotate.
- To add some fading effects you can use avidemux -> video filters -> transform filter -> fade in/out. I added 40 frames of fading to black to each avi, after cropping it to the relevant part, at the end of it.
- To make a movie (slideshow like) starting from some static images on your screen and some recorded mp3 track:
-- record your voice if needed, using Voice Recorder. I had troubles with mp3s embeded in the avi so I converted the mp3 to wav, 8KHz, mono, using Sound Converter. Write down how many seconds of audio you have.
-- use Shutter to capture your text/image of interest on screen.
-- use Gimp to adjust it to a 640x480 jpeg (or same as your avi-s). Then open the jpeg in Avidemux, set the movie fps to the same as the real avis (30fps in my case) and this jpeg becomes frame number one.
-- copy paste this frame as much as you want to fill the frames toward the total seconds of your wav. If you need to add more images, split the number of seconds in convenient parts and do copy paste as many times as needed to "cover" only that allocated share of seconds. At a 30 fps you need 1 copy and 30 paste to fill one second. The problem is that avidemux crashes at many copy paste operations, so I did cover only one second, saved it, then reopened the 1 second movie and appended it to itself 10 times for a 10 seconds slideshow of one image.
-- after building the all the static video parts for the slideshow, append them together to form the whole avi that makes the slideshow. It's length should be few miliseconds more than the number of seconds of your audio (you wrote it down earlier).
-- If you want to add a fade effect on the slideshow avi too, do it as described above.
-- save it by converting audio/video to the codecs you want (same as rest of the avis)
- Append all the prepared avi (and the slideshow avi) in the desired order using avidemux. Remember that all parts should have exactly the same characteristics in terms of video codec and audio codec as to have the whole working ok. Check that the movie can be seen and heard properly in VLC media player (for example).
- All you need now is subtitles:
-- Create the subtitle by using Gnome Subtitle, by looking at the movie, pausing it, adding text for a subtitle, again and again. This makes a very rough subtitle file with subtitles inexactly positioned. Ssave it as .srt.
-- After finishing introducing all text, it should be taken again from the beginning and by listening the voice and/or watching the movie, the subtitles time positioning should be established more accurately. For this you can use the 2 small buttons left to the movie window and under "time" and "length" indicators. When a subtitle is selected (and the movie plays) the left button if clicked establishes the beginning of its appearance, and the right one establishes the end of its appearance on the screen.
-- If during play in Gnome Subtitles some subtitles don't seem to diplay, check it is not an overlapping between that one and it's neighbors and redo start/end for each involved in this.
-- Save the subtitle after you're happy with its sync status with the movie/audio.
-- Open avidemux one more time and use Video filters->Subtitlers->Subtitlers to add the .srt. Choose a font too as without it is not doing it and ignores you silently (I choose a ttf found on disc: DejVueCondensedOblique.ttf but you can chooshe whatever).
-- save again the movie and you're done.
Not easy but fun I'd say...
Here is my result: http://youtu.be/GNAF2bvkjcg
- You're on Ubuntu or similar linux.
- You need to create a movie (e.g. for youtube) and you have:
-- some avis from your camera, (some should be 90degrees rotated as they have been filmed wrong)
-- jpegs from you computer (or screen captures)
-- a mp3 track to add on some parts of it (slideshow like)
- You need to add subtitles and some fading effects.
How I did it
- I decided to have the resulting film in m-jpeg video codec format and AC3 audio codec. I had 640x480 30fps avis from my camera, audio: mono, 8KHz. Your data might differ, what's important is to have all parts with the same parameteres before joining them together.
- To cut the interesting parts from your .avi you can use Avidemux and in this operation you can convert them to m-jpeg/ac3 format.
- To rotate the movie you can use avidemux -> video filters -> Transform -> Rotate.
- To add some fading effects you can use avidemux -> video filters -> transform filter -> fade in/out. I added 40 frames of fading to black to each avi, after cropping it to the relevant part, at the end of it.
- To make a movie (slideshow like) starting from some static images on your screen and some recorded mp3 track:
-- record your voice if needed, using Voice Recorder. I had troubles with mp3s embeded in the avi so I converted the mp3 to wav, 8KHz, mono, using Sound Converter. Write down how many seconds of audio you have.
-- use Shutter to capture your text/image of interest on screen.
-- use Gimp to adjust it to a 640x480 jpeg (or same as your avi-s). Then open the jpeg in Avidemux, set the movie fps to the same as the real avis (30fps in my case) and this jpeg becomes frame number one.
-- copy paste this frame as much as you want to fill the frames toward the total seconds of your wav. If you need to add more images, split the number of seconds in convenient parts and do copy paste as many times as needed to "cover" only that allocated share of seconds. At a 30 fps you need 1 copy and 30 paste to fill one second. The problem is that avidemux crashes at many copy paste operations, so I did cover only one second, saved it, then reopened the 1 second movie and appended it to itself 10 times for a 10 seconds slideshow of one image.
-- after building the all the static video parts for the slideshow, append them together to form the whole avi that makes the slideshow. It's length should be few miliseconds more than the number of seconds of your audio (you wrote it down earlier).
-- If you want to add a fade effect on the slideshow avi too, do it as described above.
-- save it by converting audio/video to the codecs you want (same as rest of the avis)
- Append all the prepared avi (and the slideshow avi) in the desired order using avidemux. Remember that all parts should have exactly the same characteristics in terms of video codec and audio codec as to have the whole working ok. Check that the movie can be seen and heard properly in VLC media player (for example).
- All you need now is subtitles:
-- Create the subtitle by using Gnome Subtitle, by looking at the movie, pausing it, adding text for a subtitle, again and again. This makes a very rough subtitle file with subtitles inexactly positioned. Ssave it as .srt.
-- After finishing introducing all text, it should be taken again from the beginning and by listening the voice and/or watching the movie, the subtitles time positioning should be established more accurately. For this you can use the 2 small buttons left to the movie window and under "time" and "length" indicators. When a subtitle is selected (and the movie plays) the left button if clicked establishes the beginning of its appearance, and the right one establishes the end of its appearance on the screen.
-- If during play in Gnome Subtitles some subtitles don't seem to diplay, check it is not an overlapping between that one and it's neighbors and redo start/end for each involved in this.
-- Save the subtitle after you're happy with its sync status with the movie/audio.
-- Open avidemux one more time and use Video filters->Subtitlers->Subtitlers to add the .srt. Choose a font too as without it is not doing it and ignores you silently (I choose a ttf found on disc: DejVueCondensedOblique.ttf but you can chooshe whatever).
-- save again the movie and you're done.
Not easy but fun I'd say...
Here is my result: http://youtu.be/GNAF2bvkjcg
Subscribe to:
Posts (Atom)