Creating and converting icons to gnome dia – Part I
Before I start, I’d like to say thanks to all people that are using the icons that I made. I confess that I’m surprised with a lot of mails that I’ve been receiving about this project.
I know that there are a lot of guys curious about to convert their icons to shape file format. So, finally I’m trying to dedicate a time to explain how to do that.
The first thing that we need to think is that shape files are totally limited. During my work to convert these icons I’ve noticed some details about its creation:
- Do not try to use gradient in shape files. If you need this effect you must construct this using retangular objects in a color scale.
- The format entitled plain svg by Inskscape has some differences if comparing to shape, an important difference is that colors are referenced by names in svg and referenced by hexadecimal in shape.
- Depending of the way that the object was made, probably you’ll need to remake this. Some resources used in vetorial applications doesn’t work to shape format.
- Try not to use lines when you’re drawing an object to be saved in a shape file. Sometimes, I don’t know what happens that the line looses its coordinates. So, use a thin rectangle filled in the color that you want.
- Do not use outlined objects. If you need an object outlined, you must use two objects in a different size and pick up the lower on the largest. Your largest object is your outline.
To be continued.
Convertendo arquivos com codificações diferentes
Utilizei durante um bom tempo a codificação ISO-8859-1 para editar e construir meus arquivos. Porém após a mudança para UTF-8 tive vários problemas com a codificação dos arquivos, daí que encontrei o iconv e este salvou minha vida.
Outro fato interessante também é receber arquivos com codificações diferentes de outras pessoas e ficar com aquele problema chato na acentuação dos arquivos.
O iconv serve para mudar de uma codificação para outra e possui uma sintaxe muito simples e fácil.
Para converter um arquivo de ISO-8859-1 para UTF-8 basta apenas fazer o seguinte.
# iconv --from-code=ISO-8859-1 --to-code=UTF-8 < oldISOfile > newUTF8file
Você também utilizar o inverso da situação acima:
# iconv --from-code=UTF-8 --to-code=ISO-8859-1 < oldUTF8file > newISOfile
E não limite-se somente à isto, você também pode trabalhar com outros padrões de codificação e obter o resultado que quiser. Aqui você pode saber mais sobre tipos de codificação.
Download de pacotes .deb com todas suas dependências
Apesar do mundo estar cada vez mais conectado à Internet, às vezes enfrentamos alguns problemas que nos impossibilitam de ter o acesso à rede. Um exemplo interessante seria a mudança de casa e o pedido de transferência de um serviço ADSL para um novo endereço, por exemplo.
Vivendo este problema necessitava instalar o pacote gphpedit no computador em casa. Porém não encontrava nenhuma maneira fácil de fazê-lo devido à quantidade de depedências que eu precisava copiar através da rede de um amigo e levá-las em um dispositivo móvel de armazenamento qualquer: um pendrive, cd ou algo do tipo.
Poderia até utilizar o Synaptic para procurar o devido pacote e gerar através dele um script para fazer o download das dependências, mas o objetivo era fazer diretamente pelo console.
Cheguei até a improvisar um shell script para fazer isso, mas a solução era limitada, pois o script pegava somente as dependências do gphpedit. Se alguma biblioteca necessária para a instalação do gphpedit precisasse também de uma outra biblioteca ou pacote, o script não a pegava.
Foi daí que recebi uma dica do Theo para usar o apt-rdepends e conseguir listar recursivamente todas as dependências. O único problema é que ele não tem a capacidade de fazer o download destes pacotes diretamente. E novamente tive que montar um script para fazer isso.
Uma nota é que o apt-cache também proporciona a listagem de dependências do pacote, mas não de maneira recursiva.
Caso queira ver as dependências pelo apt-cache apenas rode:
# apt-cache depends nomedopacote
Não conhecia o apt-rdepends pois não vem instalado por padrão no Debian/Ubuntu. Para instalá-lo rode:
# aptitude install apt-rdepends
Bom, depois ainda resta um trabalhinho sujo para criar o script, mas é bem fácil. Antes de começar crie um diretório para que na inicialização dos downloads os pacotes não fiquem espalhados.
# mkdir gphpedit
# cd gphpedit
Para criar o script faça:
# apt-rdpends gphpedit > depends.sh
# chmod u+x depends.sh
# vi depends.sh
Na primeira linha do arquivo adicione o interpretador: #!/bin/bash
Substitua o nome dos pacotes que possuem dependências com o seguinte comando no vi:
ESC + :%s/^[a-z]/#\1/g
Note que agora todos os pacotes ficaram com um comentário na frente. O próximo passo é alterar o valor dos termos “Pré-Depende:” ou “Pre-Depends:” para “aptitude download”. Novamente no vi faça:
ESC + :%s/Pré-Depende:/aptitude download/g
(Se seu sistema estiver na língua inglesa utilize “Pre-Depends”:).
Agora altere somente os termos “Depende:” da mesma maneira:
ESC + :%s/Depende:/aptitude download/g
(Se seu sistema estiver na língua inglesa utilize Depends:).
Ficou faltando apenas um detalhe. Apagar as informações sobre versões delimitadas entre parênteses. Nada que uma pequena expressão regular não ajude:
ESC + %s/\((.\+\)//g
Bom, agora é só executar seu script e esperar pelo download.
# ./depends.sh
Vulnerabilidade no Django i18n: Negação de Serviço
Há pouco fui checar o Security Focus e logo na index encontrei falando sobre uma vulnerabilidade na internacionalização do Django. A causa da vulnerabilidade é que o Django falha ao alocar o apontamento de dados submetido pelo usuário.
Um “hacker” mal intensionado pode explorar este problema reservando grandes valores de memória e então causar um Ataque de Negação de Serviço ou Remote Denial of Service.
As versões 0.91, 0.95, 0.95.1 e 0.96 estão vulneráveis; outras versões também podem ser afetadas.
Esta falha pode somente ser explorada se a opção ‘USE_I18N’ e o componente ‘i18n’ estiverem ativados.
Nenhum exploit foi ainda publicado, porém no site oficial do projeto já estão disponíveis os patches para correção do problema.
Você pode acessar os patches de correção diretamente clicando abaixo na versão de seu uso:
Bases controladas no Gnuteca
Iniciamos o trabalho para implementar bases controladas no Gnuteca. Estas bases serão integradas à tela de catalogação para servir de suporte à registros que não podem ser recuperados pelo z39.50, e também fazer uma gestão do conteúdo gerado pela Biblioteca.
As interfaces já foram desenhadas, porém ainda sofrerão algumas pequenas alterações na implementação para efeitos de filtragem dos dados.
O sistema contará agora com as seguintes bases controladas:
- Autores;
- Autores corporativos;
- Tabela de cutter;
- Nomes de séries / coleções;
- Editoras;
- Locais de publicação; e
- Vocabulário controlado: assunto, subdivisão geral, subdivisão cronológica e geográfica.
Para efeitos de visualização acompanhe um exemplo da tela de autores:
As demais telas seguem o modelo proposto. Através de um botão que será indexado ao lado do campo correspondente, o usuário poderá carregar as informações de uma lista pré-definida. Uma vez que a informação for selecionada nesta lista, o campo será automaticamente preenchido. Quando o usuário identificar algum erro nestas informações ele poderá modificá-las diretamente na tela. Concluindo as alterações todos os registros serão atualizados com a informação correta.
Todas as telas serão carregadas utilizando o conjunto de tecnologias AJAX. Esperamos que estas novas alterações ajudem o Bibliotecário ter um maior controle sobre a consistência dos dados e consigam transmitir a informação da melhor maneira possível.
Mais navegabilidade no Gnuteca: abas identificáveis na catalogação
Durante estes dois meses de trabalho no Gnuteca, muitas melhorias em questões de usabilidade e navegabilidade tem sido aplicadas ao software.
Uma alteração interessante que fiz há pouco foi adicionar terminologias às abas na tela de catalogação. São notáveis as diferenças, pois em contra-partida não são todos que tem a fácil familiarização com o MARC 21.
Este diferencial de identificação nas abas pode ajudar bastante quando a biblioteca não tem somente bibliotecários credenciados e que tenham o pleno conhecimento no assunto. Sabemos que a Biblioteca também pode ter estagiários, novos bibliotecários e mão-de-obra não especializada.
Mesmo em condições em que o profissional detenha o conhecimento do MARC 21, em alguns momentos temos a necessidade de realizar uma tarefa mais rapidamente e a identificação pelos códigos pode nos causar confusões imediatas, podendo gerar atrasos no trabalho e diminuição do rendimento. Com as abas identificadas podemos ter clareza no que queremos e estar menos propícios à confusões.
Tirei uma amostra da nova tela de catalogação que vem sendo implementada para que possam fazer uma avaliação deste resultado e expressarem seus comentários à respeito.
Complemento da correção de erros em javascript
Havia publicado há um tempo atrás sobre os problemas de javascript no Gnuteca, porém não fui específico o bastante de indicar em qual arquivo corrigir o problema.
Então, somente para completar o que eu havia dito, eis a resposta:
o arquivo é o /usr/local/miolo/modules/gnuteca/forms/UINovoMaterialForm.class.
Desta forma abra o arquivo para edição, siga até a linha 71: que é exatamente um fechamento de condição, ou seja, uma “}” (chave).
Após esta chave dê um [enter] e insira o código abaixo:
else
{
echo “var lookup.defaults;”;
}
Salve o arquivo e veja os agradáveis resultados.
(Obs: esta é a resposta para o comentário do Antônio)
Access Denied Gnuteca(inserir_material)
Quando havia instalado a versão 1.7rc2 do Gnuteca tive este problema, porém não dei muita importância à ele. Já que poderia ser algum erro em minha instalação.
Ainda não posso afirmar que este problema seja dos arquivos de instalação, pois até agora só tive dois relatos do problema: o meu e de outro participante da lista gnuteca-users. O problema também pode estar relacionado ao comportamento do SO que está sendo usado, mas são apenas especulações, nada concreto.
Tive este problema quando estava testando o Gnuteca no RedHat, no Debian havia funcionado perfeitamente, porém não sei se houveram alterações no pacote de instalação neste intermeio.
Bom, chega de papo!
Para corrigir este problema devemos acessar o console do GNU Linux e digitar alguns comandos. Simples até mesmo para quem não é familiarizado com o sistema do pingüin.
Primeiro precisamos remover todas as entradas do login gnuteca no banco de dados chamado bis. Isto é necessário para não ocorrem erros ou simplesmente duplicar o login quando executarmos o script de inserção das informações novamente. Então prossigamos.
offs@tirith:~$ su [enter - digite sua senha de root]
tirith:~# su – postgres [enter]
postgres@tirith:~$ psql bis [enter]
bis=# DELETE FROM cmn_users WHERE login=’gnuteca’; [enter]
bis=# DELETE FROM cmn_modules WHERE name=’gnuteca’; [enter]
bis=# DELETE FROM cmn_access WHERE login=’gnuteca’; [enter]
bis=#\q [enter]
Removemos as entradas do login gnuteca e agora precisamos adicionar o usuário novamente. Mantenha-se logado como usuário postgres, vá até os arquivos de instalação do Gnuteca. Quando acessar o diretório de instalação entre no diretório sql. No meu sistema o caminho da instalação é /usr/local/gnuteca-1.7rc2. Agora execute o comando abaixo:
postgres@tirith:/usr/local/gnuteca-1.7rc2/sql$ psql -h localhost -d bis create_user.sql [enter]
Pronto! Abra seu navegador, acesse o gnuteca e tente realizar operações de Administrador novamente. Qualquer dúvida é só comentar. Boa sorte!
Deixe um comentário
Deixe um comentário
Comentários (27)