He recibido en los últimos días varios documentos del JTC1/SC34 acerca de los progresos en el grupo de trabajo que está tratando de arreglar el OpenXML, y es impresionante lo hay de información surrealista en estos documentos.

El documento N1101/N1168 contiene por ejemplo, varios artículos en los que reconocen que hay decisiones tomadas en el BRM que no fueron incorporadas en el texto final de la norma publicada. En otras palabras, aun teniendo casi un año después de la aprobación de la norma a publicar el texto (sí, aprobado sin leer), no hubo tiempo/atención o cualquier otra cosa necesaria para hacer los cambios (algunos condicionantes de la aprobación) en el texto. Lo que más me deja enojado por esto, es que durante el BRM he preguntado acerca de quién sería responsable de verificar que todos estos cambios serían parte del texto final y la respuesta fue ITTF (como una secretaría conjunta de la ISO y la IEC). Cuando he preguntado si la ITTF realmente haría este trabajo, he recibido una respuesta intimidatoria: “Estas a dudar del ITTF, muchacho?” …

Peor que eso, es que las informaciones contenidas en este documento, para mí son suficientes para dudar de que todas las correcciones que han sido aprobados fueran aplicadas en el texto. Si antes sospechaba de que esta última versión de la especificación no era lo que todo el mundo pensaba, ahora estoy seguro que no es y creo que no hay problemas aún más graves encontrados por que la mayoría de la gente, como yo, se niega a mirar nuevamente las malditas 6.000 páginas.

En el documento N1171, uno de los grupos de trabajo de SC34 anuncia que fueran encontrados problemas en las fuentes del OpenXML y enviarán un informe de error sobre la cuestión al grupo responsable de la reparación de la norma (se ve gracioso, pero hasta hoy se están encontrando defectos…).

El documento N1183 justifica la subdivisión de las partes actualmente existentes de la norma, al decir que esto es necesario para que se pueda corregir algunos errores señalados, añadiendo a la especificación nuevas “pequeñas” funcionalidades (y que está bien, ahora que la ISO ha aprobado la norma, pueden escribir lo que quieras, ¿no?).

Me salvó la mejor para el final, el documento N1187, que nos relata que el OpenXML contiene “errores involuntarios que pueden impedir que los documentos existentes sean representados en este nuevo formato.” El soporte a el “legado de documentos” fue la razón principal utilizada para que se desarrollase y aprobase el OpenXML, y fue también la razón por la cual varios países apoyaron el desarrollo y la aprobación de la norma. Como eso se explica ahora ? En este documento, se explica también los criterios que se utilizarán para especificar los cambios que se desarrollarán a fin de que puedan hacerlo con rapidez (en otras palabras, abusan de la interpretación de las directivas del JTC1  para obtener los cambios necesarios o deseados si que se haga mucho ruido en el proceso).

Lamentablemente no puedo poner todos estos documentos para aquí en mi blog por que debe ser documentos rescritos del SC34 (0% de transparencia), pero creo que, tarde o temprano, ellos deberán ser publicados en alguna parte (y por supuesto, quién es miembro de su NB ya los debería haber recibido).

Desde niños he aprendido a no firmar el papel en blanco, pero creo que esto no es una lección valiosa en otros países.

Me gustaría de ver la contestación a algunas preguntas:

Brasil, Sudáfrica, India y Venezuela, tenían o no la razón cuando apelaran a la ISO (y fueran ignorados completamente)?

Sera que los mismos señores del board de la ISO, que ignoraran los protestos, están ahora siguiendo el desarrollo y documentos como los que he comentado aquí?

¿Quiénes son responsables de todo eso? Cómo se paga?

Received in recent days several documents from JTC1/SC34 reporting the progress at the working group that is trying to fix the OpenXML, and it’s impressive and surreal what one may find in those documents.

The document N1101/N1168 contains for example, several items in which they recognize that there are decisions made in the BRM (BRM resolutions) which were not incorporated into the final published text of the standard. In other words, even taking almost a year after the aproval of the standard to publish the text (yes, approved without reading), there wasn’t time/attention or anything else necessary to assure that the changes were published in the text (most of those changes, “conditioned” the approval). What makes me much more angry about this is that during the BRM I asked about who would be responsible for verifying that all these changes would be part of the final text and the answer was ITTF (kind of joint ISO/IEC secretariat). When I asked if the ITTF would really make this work, I received as a reply the intimidating: “You are doubting the ITTF, kid ?”…

Worse than this, the informations inside this document are sufficient for me to doubt that the approved/recommended corrections where even implemented. If before this document I suspected that the final version of the specification wasn’t what everybody thought, now I’m pretty sure about it and I think that we didn’t find even more severe problems there because most people, like me, refuses to look at those damn 6000 pages again.

On the document N1171, one of the working groups of SC34 announces that they’ve found problems in the OpenXML fonts specification and will submit an error report about it to the group responsible for repairing the standard (looks funny, but until today there are folks finding defects … ).

The document N1183 justifies the subdivision of the already existing parts of the standard to saying that to correct some errors pointed out, new “minor” features need to be added to the specification (and that is really cool, because now that the ISO has already approved the standard, they can write whatever they want , isn’t it?).

I saved the best for the end: document N1187. This one says that OpenXML “as is” contains unintentional errors that may prevent existing documents to be fully represented in this new format.  It is amazing because the legacy support was alleged as  the main reason for OpenXML development and approval at ISO, and also the reason why several countries supported the development and approval of the standard. In this document, they also explain the criteria that will be used to specify the changes that will be developed, so that they can do it all really quickly (in other words, they go trough the breaches of the JTC1 directives to get these changes incorporated into standard already approved without making much noise about it).

Unfortunately I can not put all these documents here, to allow access trough the blog, because they should be restricted SC34 documents (yep, zero transparency), but I believe that sooner or later they will be published somewhere (and of course, NB members should already received those).

Since I was a young boy I’ve learned to not sign blank papers, but I think that this isn’t a valuable lesson in other countries.

I would like to see answered some basic questions:

Brazil, South Africa, India and Venezuela were right or not when appealed (and had their appeals ignored by the ISO)?

Do the same gentleman at the ISO board, that ignored the appeals, are following the development work and documents commented here?

Who is responsible for all this, and how he will pay?

Recebi nos últimos dias diversos documentos do JTC1/SC34 relatando os avanços nos trabalhos do grupo que está tratando da correção do OpenXML, e é impressionante o que existe de informação surreal nestes documentos.

O documento N1101/N1168 contém por exemplo, diversos itens em que eles reconhecem que existem decisões tomadas no BRM que não foram incorporadas ao texto final publicado da norma. Em outras palavras, mesmo levando quase um ano após a aprovação da norma para publicarem o texto (sim, aprovaram sem ler), não houve tempo/atenção ou qualquer outra coisa necessária para que as alterações condicionantes da aprovação fossem publicadas no texto. O que mais me deixa irritado nisso é que durante o BRM eu perguntei sobre quem seria o responsável por verificar que todas estas alterações fariam parte do texto final, e a resposta foi ITTF (secretaria conjunta entre ISO e IEC). Quando perguntei se o ITTF iria realmente fazer este trabalho, recebi como resposta um intimidador: “Você está duvidando do ITTF, garoto ?”…

Pior que isso, é que as informações existentes neste documento são suficientes para que eu duvide que todas as correções aprovadas foram mesmo implementadas. Se antes eu suspeitava que esta versão final da especificação não era o que todos pensavam, agora tenho certeza que não é e acho que não foram encontrados problemas mais graves ainda pelo simples fato de que a maioria das pessoas, como eu, se recusa a olhar aquelas malditas 6.000 páginas de novo.

No documento N1171, um dos grupos de trabalho do SC34 alerta que encontrou problemas nas fontes do OpenXML e que irá enviar um relatório de erros sobre o assunto ao grupo responsável por consertar a norma (parece piada, mas estão encontrando defeitos até hoje…).

O documento N1183 justifica a subdivisão das partes da norma dizendo que para que se possa corrigir alguns erros apontados, novas “pequenas” funcionalidades precisam ser adicionadas á especificação (e isso é bem legal, agora que a ISO já aprovou, podem escrever o que quiser, não é mesmo ?).

Guardei o melhor para o final, pois no documento N1187, afirmam que o OpenXML contém “erros não intencionais que podem impedir que documentos existentes sejam representados neste novo formato”. Não era o suporte ao legado a principal razão para que o OpenXML fosse desenvolvido, razão pela qual diversos países apoiaram o desenvolvimento e a aprovação do padrão ? Ainda neste documento, explicam qual será o critério utilizado para especificar as alterações que serão desenvolvidas, para que possam faze-lo com rapidez (em outras palavras, andam pelas brechas das diretrizes do JTC1 para conseguir fazer estas alterações serem incorporadas á norma já aprovada sem levantar poeira).

Infelizmente não posso colocar estes documentos para que todos acessem aqui no Blog pois são documentos restritos do SC34 (transparência zero), mas acredito que cedo ou tarde eles devem ser publicados em algum lugar (e claro, quem é membro de seu NB já deveria ter recebido).

Desde criança aprendi a não assinar papel em branco, mas me parece que este não é um ensinamento tão valioso em outros países.

Gostaria de ver respondidas algumas perguntinhas básicas:

O Brasil, África do Sul, Índia e Venezuela estavam ou não com razão quando apelaram (e tiveram seus apelos ignorados pela ISO) ?

Será que os mesmos senhores do board da ISO que ignoraram os apelos recebidos estão acompanhando o desenvolvimento dos trabalhos e os documentos que comento aqui ?

Quem são os responsáveis por isso tudo ? Vão pagar como ?

Para celebrar el DocumentFreedom Day (DFD) mañana, la ODF Alliance Capítulo Brasil y 4Linux  van transmitir en directo mañana a las 7 pm (GMT -3) un talk show conmigo (Jomar Silva), Luiz Maluf (Sum Microsystems) y Marcelo Marques (4Linux y HackerTeen).

Durante una hora, contestaré todas las preguntas acerca del ODF enviadas a boteconet EN 4Linux.com.br (usted puede enviar sus preguntas en inglés / español / portugués antes o durante el evento). John maddog Hall ya nos ha enviado su pregunta.

El archivo de audio estará disponible para descargar a partir del final del programa, como un podcast.

El talk show será sólo en portugués, por lo que será una muy buena oportunidad para entrenar tu portugués de Brasil (yo se que usted planea llegar a Bahía o Río por lo menos una vez en tu vida, ¿ok?).

Para escuchar el programa, conectar el reproductor VLC para boteco.4linux.com.br: 8003 (usando HTTP / HTTPS / FTP / MMS).

Esperamos recibir (y contestar) a sus preguntas.

Grand DFD a todos

To celebrate the DocumentFreedom Day (DFD) tomorrow, 4Linux and ODF Alliance Chapter Brazil will live broadcast tomorrow at 7 pm (GMT -3) a talk show with me (Jomar Silva), Luiz Maluf (Sum Microsystems) and Marcelo Marques (4Linux and HackerTeen).

During one our, we’ll answer all questions about ODF send to boteconet AT 4Linux.com.br (you can send your questions in English/Spanish/Portuguese before the event begins or during the show). John Maddog Hall already sent us his question.

The event’s audio file will be available to download after the end of the program, as a regular PodCast.

The talk show will be only in Portuguese, so it will be a very good opportunity to train your Brazilian Portuguese (everyone plans to come to Rio or Bahia at least one time on your life, ok ?).

To listen to the program, connect your VLC player to  boteco.4linux.com.br:8003 (using HTTP/HTTPS/FTP/MMS).

Hope to  receive (and answer) your questions.

Happy DFD to everyone

Amanhã é comemorado internacionalmente o DocumentFreedom Day (DFD’09), e para marcar a data no Brasil, vamos realizar junto com a 4Linux um Boteco 4Linux especial.

Para quem não conhece,  o Boteco 4Linux é um talk show transmitido ao vivo pela Internet, onde os convidados respondem as perguntas enviadas pelos internautas (antecipadamente ou ao vivo), e isso acaba tornando o evento muito interessante, pois nunca sabemos o rumo que a conversa vai tomar. Após o término do programa, o arquivo de áudio fica disponibilizado para download (como este, de quando estive lá falando sobre ODF e OpenXML).

Será uma excelente oportunidade para todos vocês fazerem “aquela” pergunta sobre ODF, seja ela qual for.

Estarei no estúdio com o Marcelo Marques (4Linux e HackerTeen) e Luiz Maluf (Sun Microsystems) e até o John Maddog Hall já enviou sua pergunta.

Escolhemos o horário das 19:00 hs para permitir que todas as pessoas que participarão de eventos locais de comemoração do DFD possam também participar do programa (passe no Boteco antes do boteco… entendeu ?).

Mais informações sobre como se conectar ou enviar sua pergunta podem ser encontradas aqui (e antes que alguém pergunte, vai rolar uns brindes para as melhores perguntas).

Espero todos vocês no Boteco 4Linux antes de irem para o boteco de verdade (ninguém é de ferro, não é mesmo) !

Normalmente no escribo acerca de aplicaciones ODF, pero he decidido a escribir este post para ayudar a las personas que están enfadados con OpenOffice, por que el cambió la formatación del texto en las diapositivas en una presentación.

El síntoma principal del problema es tener el texto de las diapositivas con su formatación cambiada, muchas veces el texto suele ser más grande que la área de la diapositiva y hay una explicación muy sencilla para eso: Usted hay utilizado un tipo de fuente que está instalada en su ordenador pero no en el equipo en el que la presentación va ser utilizada !

Este problema suele producirse durante la edición de una presentación de Windows y tratar de utilizar Linux para presentarla, pero, de hecho, también puede ocurrir cuando se cambia el equipo entre la edición y la presentación del documento (incluso utilizando el mismo sistema operativo y la misma versión del OpenOffice).

Muchas personas se quejan de este problema para mí (sobre todo los demás oradores en los eventos), aunque la mayoría culpa OpenOffice, hay algunas personas que dicen que se trata de un problema del ODF (de hecho, la gente sigue siendo muy confusa y con el estándar y la aplicación del estándar, pero esto podría ser explorado en otro post). De hecho, el problema es la pequeña pieza que causa 98% de los problemas de los sistemas informáticos, la pequeña pieza que se encuentra entre el teclado y la silla, también conocido como “usuario” (Sí, usted: D).

Viendo que yo hago muchas presentaciones en diferentes lugares (siempre usando ODF), y que casi nunca sé lo que encontraré cuando llego al sitio del los eventos, yo siempre uso en mis presentaciones una fuente que nunca me dio problemas: Bitstream Vera Sans.

Espero que este texto ayude a muchas personas que tienen este problema y me gustaría saber si alguien conoce cualquier otra fuente que también está ampliamente disponible (por favor, deje el nombre de la fuente en los comentarios).

I usually don’t blog about ODF applications, but decided to write this post to help people that are angry with OpenOffice, because it mess with the text in slides.

The main symptom of the problem is to have the text of the slides unformatted, usually being many times larger than the area of the slide and there is a very simple explanation to that: You used a font that is installed on your computer but not on the computer where the presentation will be viewed !

This problem typically occurs when editing a presentation on Windows and try to use Linux to present it, but in fact it can also occur when you change the computer between edition and presentation (even using the same operating system and same version of OpenOffice).

Many people complain about this problem to me (especially other speakers in events), although most blame OpenOffice, there are some folks who say that this is an ODF issue (indeed, the people still very confused with the standard and the standard implementation, but this could be explored on another post). Indeed, the problem is that small piece that causes 98% of computer systems problems,  the small piece that lies between the keyboard and the chair, also known as “user” (yep, you :D).

Seeing that I used to do many presentations in different places (always using ODF), and that I almost never know what I’ll find when I come to the site of the event, I always use in my presentations a font that has never let me down: Bitstream Vera Sans.

I hope this tip help many people who are having this problem and would like to know if someone knows any other font that is also widely available (please, leave its name on comments).

Eu não costumo escrever sobre aplicações que suportam o ODF, mas resolvi escrever este post para ajudar as pessoas que andam meio irritadas com o OpenOffice, pois ele “bagunça” o texto nos slides.

O principal sintoma do problema é  ter o texto dos slides desformatado, ficando muitas vezes maior do que a área do slide e a explicação dele é muito simples: Você usou uma fonte que está instalada no seu computador mas não no computador onde a apresentação vai ser visualizada !

Este problema ocorre normalmente quando se edita uma apresentação no Windows e tenta utiliza-la no Linux, mas na verdade ele também pode ocorrer quando se troca de computador (mesmo usando o mesmo sistema operacional e mesma versão do OpenOffice).

Muita gente reclama deste problema comigo, principalmente em eventos, e apesar da maioria culpar o OpenOffice, já existem alguns que dizem que isso é defeito do ODF (aliás, as pessoas confundem muito o padrão com a aplicação, mas isso é assunto para outro post). Na verdade, o problema é aquela pecinha que causa 98% dos problemas nos sistemas, pecinha esta que fica entre o teclado e a cadeira, também conhecida como usuário (ou seja, você :D).

Como faço apresentações em muitos lugares diferentes, sempre utilizando ODF, e quase nunca sei o que vou encontrar quando chego ao local do evento, procuro sempre utilizar em minhas apresentações uma fonte que até agora não me deixou na mão: Bitstream Vera Sans.

Espero que esta dica ajude a muita gente que anda batendo a cabeça com este problema, e gostaria de saber se alguém aí conhece mais alguma fonte que esteja amplamente disponível também (deixe o nome dela nos comentários).

Después de pasar meses discutiendo sin resolver un grave problema con mi proveedor de servicios de banda ancha (NET) y seer sumariamente ignorado por la empresa, decidí poner una queja formal en la ANATEL (el organismo que regula todos los servicios de telecomunicaciones en Brasil), como lo hice en el pasado.

En el sitio Web de la ANATEL, descubrí que su sistema de denuncias se ha actualizado y cuando traté de mi registro en el nuevo sistema que se encuentra que el sitio, descubrí que el registro no funciona en Linux.

He probado lo mismo en un equipo diferente y he hablado con varios amigos que se enfrentan el mismo problema, un gigantesco absurdo.

No puedo entender por qué todavía tenemos gente que no entiende que el acceso a los servicios públicos sin discriminación es un derecho humano! No es aceptable que un usuario de Linux tiene la obligación de adquirir una licencia de Windows para comunicarse con el gobierno y es aún menos aceptable en un gobierno que está haciendo demasiado para adoptar estándares abiertos, y que ya tienen la mayoría de sus sitios web basados en Estándares Abiertos.

Inspirado por mi amigo de Sudáfrica, Aslam Raffee que ha enfrentado un problema similar en su país, he enviado hace unas horas la siguiente denuncia a la Comisión Nacional de Derechos Humanos y Ciudadanía:

“Señores,

Tengo problemas con mi proveedor de servicios de banda ancha y después de meses en contacto con ellos intentando resolver las cuestiones, no tuvo ningún éxito. He decidido presentar una queja formal en Anatel, como lo hice el año pasado.

En la página web de la ANATEL, me doy cuenta de que el sistema de denuncias se ha cambiado y no puedo hacer que mi inscripción en el nuevo sistema mediante la utilización del navegador de Internet Firefox en sistema operativo Linux (probado en dos ordenadores distintos con diferentes versiones de Firefox y Linux y no funciona).

En los últimos días, hablé con diversos amigos y descubrí que no soy el único que está sufriendo este problema y he podido comprobar que el registro en el sitio sólo funciona correctamente en el sistema operativo Windows.

No tengo el sistema operativo Windows instalado en mi equipo y no deseo comprar una licencia de Windows para acceder a un servicio público.

Por lo tanto, no estoy en condiciones de acceder a un servicio (de apertura formal de denuncias a través de Internet) , y me siento discriminado por ANATEL. Yo entiendo que han otras maneras de obtener el servicio, es decir, a través de contacto telefónico, pero si el servicio electrónico es una opción a disposición de cualquier ciudadano, no puedo sufrir este tipo de discriminación.

Esta es una violación de los artículos 2, 7 y 21.2 de la Declaración Universal de los Derechos Humanos y le pido a esta comisión para investigar esta violación y notificará a los responsables.

Miles de otros usuarios en Brasil están atravesando el mismo problema, y la mayoría de ellos no son conscientes de que la no discriminación y la igualdad de acceso a los servicios públicos a través de Internet es, ante todo, un derecho humano.

Estoy disponible para cualquier aclaración necesaria. “

Espero que esto se traducirá en algo positivo, y invito a todos los que enfrentan a problemas similares a enviar una apelación o una queja formal a la Comisión de Derechos Humanos de sus países, basados en los mismos artículos de la Declaración Universal de los Derechos Humanos que he usado.

Agradezco a los amigos de Digistan, por me abrir los ojos sobre la relación entre los estándares abiertos y los Derechos Humanos y a Aslam Raffee que me diera el ejemplo.

Tengo la intención de mantenerlos informados, si voy a recibir cualquier comentario de la comisión.

Pido a todo el mundo para ayudar a la divulgación de esta iniciativa: Debemos luchar por nuestros derechos!