Xamanian

d780, novamente lhe agradeço pelos comentários e dicas. Tempos atrás iniciei a tradução do lang do Nextgen, fundindo-o com este que postei. O problema é que não uso o Nextgen, além de não parar de sair modificações nas UXs (onde fica skins, etc.) que mudam a mesma frase sem mais e nem menos, é terrível trabalhar assim. Outro problema é adaptar as frases já existentes para Primo e usá-la no Nextgen; outra coisa que dá muito trabalho, pois as frases mudam, mas significam a mesma coisa, o que implica em olhar na prática. Não dá para pegar uma tradução já feita e usar, até porque divirjo muito do que vejo por aí (mas respeito e incentivo tal trabalho, que é enorme). Tenho muita coisa feita e que não está presente no último lang; talvez um dia finalize. Ah, nem falei das vozes TTS... hehehehe Grande abraço!!!

Raimundo, baixe o arquivo txt em anexo e use um dos links presentes no mesmo para download; a senha está no txt também. Abraços. Txt atualizado em 27/10/2019: GPS Clube.txt

Caro amigo d780, comentarei por partes. (1) Você tem razão, realmente não fui claro sobre as skins modificadas. Claro, se um ícone, por exemplo, for alterado, não é preciso apagar a Save. E nem por isso skins que tiveram ícones alterados deixa de ser skins modificadas. O que faltou dizer é que skins que são modificadas em sua programação (LUA) exigem que a pasta Save seja apagada. Esse é o caso das skins que modifiquei, as do Rafael (Ultimate) e do Ziko, por exemplo. Já a ausência de arquivos de extensão bmp implica em travamento do Primo, com exibição do nome do arquivo faltante (um por vez) e a necessidade de reiniciar o navegador. O problema com o POI citado post acima é devido a uma nova programação nas skins ZK, daí a necessidade de apagar a Save. (2) Realmente o lang que disponibilizei não continha as duas linhas que citou. Obrigado, já inseri. Por outro lado, uso este mesmo lang com Primo para Android e sempre aparece a opção de estacionamento, que na verdade significa oferecimento de estacionamentos quando se chega ao destino. Uso skin diMka e nunca tive problemas quanto a isso. Na verdade, nós dois sabemos, a ausência de uma tradução no lang não impede que um recurso fique indisponível como função ou facilidade, o que o ocorre é um ou mais campos sem tradução, isto é, o campo fica no idioma original usado na programação. Edit: esqueça o que falei no último parágrafo (apesar de estar correto). Você se referia a subcategoria Estacionamento que aparece na categoria Automóveis. Sim, estava aparecendo no Primo para WinCE, mas não aparecia para Primo para Android. Valeu! (3) Sim, as categorias de POI têm seus mistérios... Por exemplo, os POI da TT ignoram maiúsculas e minúsculas nos arquivos de extensão icons do branding.zip, mas os POI da Here deve ser apresentados corretamente, sob pena de problemas. As categorias de transportes, bancos, restaurantes, postos de combustíveis e outras geralmente não dá problema para montar o branding. Já outras, como cinema, escolas, algumas de comércio varejista, etc. são problemáticas. Tem que usar o lang e procurar algum POI~ no dictionary.lang que possa ser testado, ou seja, é "na unha" mesmo, dá muito trabalho. Para piorar, estas subclassificações parecem não obedecer uma lógica. Daí ser comum ver coisas como Artex (loja de roupas de cama) aparecer em Farmácias... Obrigados pelos ótimos comentários que fez; abração!

Mas vou tentar, só espero que me dê um tempinho... (mas pode me cobrar, não me incomoda -- é que ando sem tempo e posso esquecer). Abração!

Meyer toda skin modificada exige que a pasta Save seja apagada para que as alterações passem a vigorar. Isto é normal. Percebi isso (junto como o amigo Adinis) quando "aumentamos" o número de pontos de alerta para 24 (depois para 31; o Fidelis ajustou para 32, mas a partir do que fizemos). Insisto, é normal. Mas no caso da Ultimate ZK muita coisa foi feita e em LUA (a linguagem de programação), que exige que a pasta Save seja apagada. No caso dos POI, realmente não faz sentido para mim, pois não é comum mexer nestas coisas -- usa-se o padrão diMka e nada mais. Ou seja, não sei responder a sua pergunta. Por outro lado, apresento algo que tem mexido comigo de tempos para cá: no Primo para WinCE, na categoria Automóveis, aparece a opção "Estacionamento". Esta mesma opção não aparece no Primo para Android. As licenças usadas são as mesmas nos dois casos, o arquivo sys.txt é o mesmo. Pergunto: Por que há diferença entre versões de sistemas operacionais distintos, mesmo com a mesma versão do navegador GPS, o Primo? Tudo é igual, inclusive, óbvio, os arquivos de POI. A coisa não é tão simples assim... Abração!

Super Mouse, agora entendi o que deseja: voltar com o menu à esquerda e que é original das skins diMka. É isso? Se sim, não sei como lhe ajudar, pois não sei o que o amigo Ziko fez. Sei que ele se propôs a personalizar uma skin, a partir da Ultimate, de acordo com o gosto pessoal dele. E fez com maestria! Mas não acompanhei tudo o que ele fez, mesmo embora tenhamos (ele e eu) compartilhado boas ideias --, mas fiquei restrito a adotar apenas o que me interessava naquela época. Pense assim: uma skin modificada (seja a partir de uma diMka original, ou mesmo uma Gurjon) deve ser usada como é apresentada. As mod's (modificações, personalizações) devem ser feitas a partir das originais. Mudar algo a partir de uma mod é um trabalho grande, pois quem modifica deixa "esconderijos" (falo por mim, sei que todos assim agem). É mais fácil pegar uma skin original (diMka, Gurjon, etc.) e introduzir modificações a partir de outras do que pegar uma skin já "trabalhada" e tentar mudar. É possível, mas dá trabalho. Eu prefiro trabalhar a partir das skins originais e usar boas ideias, mas ajustando-as de acordo com o que quero -- é mais produtivo. Mas nem por isso deixarei de analisar a skin que falou, vou analisar o (belo) trabalho que o Ziko fez. Se conseguir algo que possa te ajudar, assim o farei. Abração!

Super Mouse, vou dar uma olhada na skin Ultimate mod ZK e ver o que consigo. Por outro lado, já antecipando, não acredito que seja possível colocar a barra no formato vertical, seja no lado esquerdo ou direito. Motivo: as skins diMka já ocupam este espaço com os menus esquerdo e direito. Retirar estes dois menus para substituí-los por outra ferramenta não seria uma tarefa simples (aliás, insisto, nem sei sei se é possível; teria que pensar muito). Porém, retirar a barra ou usar um modo para que a mesma não seja exibida, não seria complicado. Motivo: esta skin é baseada na Ultimate do Rafael e esta permite ocultar a barra. Assim sendo, os comandos para não exibir a barra inferior são aqueles presentes na skin Ultimate original. Mas preciso olhar as duas e ver o que foi feito. Abração!

Amigo Super Mouse, a caixa de entrada para MP está lotada, por isso não conseguiu comunicar comigo. Já apaguei as mensagens, acho que não terá mais problemas. A questão é que o limite de MP é baixo... Bem, as únicas skins diMka que conheço que usam uma barra inferior são TomSoft, Ultimate (e as mods feitas por mim) e Ultimate ZK (mod feita pelo amigo e sumido Ziko). Em todas elas é possível desabilitar a barra inferior. Se existe outra diMka com barra inferior (neste caso, desconheço), então é preciso ter uma em mãos, pois os comandos podem diferir em relação a estas que citei. Cada recurso introduzido em uma skin, quando comparado com uma skin original (sem modificações), tem programação distinta, não existe um procedimento universal, digamos. Mas é claro que as pessoas tomam uma ideia e modificam os parâmetros (funções, nomes, etc.) só para parecer original; está cheio destas coisas por aí. Mas não falo como crítica, é assim que a coisa rola: estudo, entendimento e aperfeiçoamento. Em suma, preciso saber qual a skin exata que você usa. Se for mais difícil de encontrar, peço-lhe que me envie um link contendo uma delas (pode ser por MP mesmo). Abração!

Pessoal, o primeiro post foi atualizado com nova versão do anexo .txt. Este contém novos links com atualização do branding para suporte aos últimos arquivos de POI. Caso notem falhas, problemas, etc., favor reportar para que correções sejam feitas. [ ]'s .XA. Edit: para evitar o problema de não exibição correta de alguns ícones, sugere-se apagar o arquivo poi_visiblities.txt que fica na subpasta \save\profiles\01.

Pessoal, até logo mais irei disponibilizar um branding atualizado. Ele dá suporte para os últimos POI, mas também para as versões anteriores. Será como na versão do primeiro post, isto é, para Primo WinCE e Android, bem como Nextgen; em todas as resoluções. Quando atualizar os links no primeiro post, volto aqui, em novo post, para avisar. [ ]'s .XA.

Nelson, farei isso sim, mas lhe peço um tempinho adicional. Ando meio sem tempo e sem condições para organizar as coisas sobre GPS, mas tenho tudo comigo e vou postar. Incluo aí o branding que havia prometido e que não tive tempo para postar, apesar e ter finalizado tudo, que já faz um tempão. No máximo até este final de semana, mas me cobre se achar que estou demorando (não é incômodo). Abração!

Pessoal, o txt do primeiro post foi atualizado. A diferença desta versão postada, antes e hoje, é que foi feita uma tradução (pelo .XA.) para o português BR, uma vez que a original não tem esta tradução. [ ]'s .XA.

Maurício, estou acompanhando este tópico desde o início, mas confesso que não entendi a sua dúvida. Você deseja aumentar o tamanho das placas verdes/azuis que o ROP postou? Se sim, sem chances, pois as imagens fazem parte do arquivo FJV, ou seja, as figuras de junções não são bmp's tradicionais. Por outro lado, sim, é possível mudar o tamanho das junções (mini, mid jv, etc.), mas de forma proporcional, como já falei antes. Se o caso está relacionado as setas indicativas de pistas (aquelas azuis com setas brancas, embaixo ou acima da tela), aí a coisa muda um pouco, mas é preciso mexer no template e não apenas no tamanho do bmp. Abração!

Maurício, novamente lhe peço desculpas, mas só agora vi este tópico (falta de tempo mesmo...). O que você quer foi feito pelo amigo Adinis, na época em que trabalhávamos no Enterprise e no Star Wars. Nunca gostei da ideia, mas ele sim, mais do que isso, ele insistiu e levou adiante a ideia da midi-jv. Ninguém fez isso antes, foi ele o pioneiro (no mundo). A questão de dividir a tela ao meio não é nada de mais, o segredo consiste em reposicionar o cursor/carrinho no centro da outra metade, ou seja, um deslocamento proporcional e não apenas uma divisão de tela (sim, caso contrário poderia surgir uma junção que encobriria o carrinho). No início o Adinis trabalhou apenas as junções da NNG (data.zip), depois ele conseguiu ajustar as junções do arquivo fjv. Não me lembro detalhes da programação, ou seja, não posso afirmar que aquilo que foi feito à época funciona com as junções fotorrealísticas (acho que sim). Sei que tenho as junções que ele modificou naquela época, mas preciso procurar aqui. Tais modificações foram feitas em diMka 1.7.0 e depois nas 1.7.1, mas todas do tipo GpsForum. Eu, que nunca gostei das midi e mini junções, simplesmente retirei o recursos nas skins modificadas por mim. Teria que analisar os códigos que ele usou para lhe auxiliar, de memória não dá. Mas só aquilo que o nosso colega Secay sugeriu acima, simplesmente não funciona (só se os demais códigos do Adinis estão mantidos em sua skin). Tentarei olhar isso para você, mas ainda estou sem tempo. Assim sendo, se demorar mais do que esta semana, me cobre depois. Não é difícil pegar os códigos usados pelo Adinis e testar, mas, por outro lado, não posso garantir que funcionarão da maneira que você quer. Abração!

Cláudio, acho que, no caso do Primo, não é neste arquivo que você citou. O start.ui (e start.lua) realmente está(ão) relacionados com o carregamento do navegador, mas no caso do Primo o loading pode ser configurado no sys.txt. Assim: [loading] loading_bmp=loading.bmp progressbar_bmp=loading_progressbar.bmp progressbar_end_bmp=loading_progressbar_end.bmp show_progressbar=1 show_statustext=1 text_align=2 ; 0 1 2 = L C R text_fontsize=25 Acima, L = esquerda, C = centro e R = direita. Ou seja, a posição do texto que aparece durante o carregamento. Note a primeira linha do parágrafo, é o comando para carregar o arquivo de loading. Abração!

Maurício, faça mais um teste com o loading: crie um arquivo jpg (isto é, converta o seu bmp já pronto para jpg) e use os dois arquivos: loading.bmp e loading.jpg. Como lhe disse antes, o Primo lê naturalmente um jpeg se renomeado para bmp, mas é possível usar um jpg diretamente mexendo nas configurações (já vi Primo antigos assim). Veja se funciona e me reporte depois. Abração!

Maurício e demais colegas, começo observando que estou sumido do fórum apenas por apertos profissionais e não por descaso. Bem, afirmo que a skin sempre tem prioridade em relação ao data.zip. Inclusive têm várias skins com loading e exiting internamente e funcionando como o esperado. A questão é simples de entender: os arquivos no Primo (por exemplo) são zip, compactados. Então o executável descompactada, primeiro, o data.zip, depois o restante (branding => ux => skin). Obviamente que arquivos com o mesmo nome serão sobrescritos e, portanto, será "lido" o último deles. Esta é a lógica básica. O problema que você está enfrentando deve ser por outro motivo. Apesar de ter dito que as dimensões, formato (bmp), etc. estão corretas, ainda podem restar outras coisas. Vamos por partes. Se uma pessoa quiser loading/exiting diferentes para os modos diurno e noturno, então um par deve estar na pasta da resolução e outro par na subpasta skin_night. A ordem é assim: skin (digamos, 800_480) => skin_night. Caso não exista um arquivo na subpasta skin_night, mas sim na pasta da resolução, então este terá prioridade. Caso exista um (ou mais) arquivo(s) na subpasta skin_night, bem como na pasta da resolução, o(s) arquivo(s) da skin_night terá prioridade. Como falei acima, não basta ter os arquivos de tamanho correto, formato correto, etc.; é preciso observar detalhes. Por exemplo, se o data.zip que você está usando tem loading e exiting na subpasta skin_night da resolução usada, caso não estejam presentes na skin_night da skin modificada e caso o teste tenha sido feito durante a noite, então aparecerá aqueles arquivos do data.zip. É importante observar que o Primo tem loading e exiting distintos para os modos diurno e noturno. Assim, os arquivos da skin só terão prioridade se os correspondentes arquivos estiverem presentes nas duas pastas: na da resolução e na skin_night correspondente. Além disso, também é preciso certificar que não existam módulos ux, branding, etc. que possam conter arquivos deste tipo. Sugestão: verifique se os arquivos loading e exiting estão presentes na resolução e skin_night em sua skin modificada. Caso queira o mesmo para os modos diurno e noturno, basta copiar os arquivos para as duas pastas citadas: caso queira um visual distinto para os dois modos, basta ter ambos os arquivos nas duas pastas, mas selecionando o visual corresponde para cada pasta. Caso o problema persista, então desconfie de arquivo corrompido ou fora do padrão. Explico: o fato de um arquivo ter extensão bmp não significa que todos são do mesmo tipo, idem para jpg, etc. A codificação e o número de cores é importante, pois o Primo é chato com estas coisas. Além disso, gostaria de lembrar que um arquivo bmp é sempre grande, o que consome mais memória (sim, um vez que um arquivo é aberto no Primo, ele continua aberto, mesmo não aparecendo, pois o Primo trabalha com camadas, exibindo sempre a última, mas os arquivos estão lá, abertos e consumindo memória). Uma ideia é usar arquivo jpg ("jota peg"), que é menor e o Primo aceita, mas com uma "manobra": o Primo não lê arquivo jpg diretamente, mas se você salvar um arquivo em jpg e depois renomear a extensão para bmp, então o Primo funciona corretamente. Exemplo: seja xxx.jpg o arquivo jpeg, basta renomeá-lo para xxx.bmp e inserir em algum arquivo zip do Primo. Só isso. Tantos os arquivos bmp e jpeg devem ser salvos em formato padrão, nada de OS2, mac, etc. Também deve ser evitado bmp com canal alpha (isto é, com transparência) nos arquivos de loading e exiting, pois problemas podem surgir. Revise tudo e teste novamente, garanto que funciona. Se mesmo assim tiver problemas, avise. Estou diminuindo a correria e em breve terei mais tempos para os amigos de fórum, tentando ajudar com as dificuldades ou entendimentos sobre certos assuntos. Abração! PS: vi nestes dias que havia perguntado algo sobre as vozes, não tive tempo para ver antes e nem de responder. Farei tal coisa quando conseguir mais tempo.

Maurício, até onde eu sei, as diMka nunca permitiram leitura do sys.txt, de modo que as frases lá presentes são ignoradas pela TTS. Sys.txt somente skin padrão (ou suas derivadas diretas, com as Gurjon's, ou Ak_Gu). Bem, nunca testei estas coisas, pois sempre preferi bipes, mas com os comandos que informei no post anterior, talvez tenha alguma combinação que permita as diMka usar a TTS para ler o sys, mas insisto em dizer que desconheço. Acho que só da maneira que falei mesmo... Abração!

Maurício, a solução que você deseja é fácil, já que cita o uso da skin diMka. Faça o seguinte: 1. Baixe o arquivo do link abaixo: https://www.solidfiles.com/v/6aVZn5Vazw7ma 2. Entre no menu de configurações da diMka e depois siga para o menu de configurações da voz TTS Pro (não é aquele de alertas e aviso, é outro mais abaixo). 3. Estando em tal menu, localize (mais abaixo) a opção de configurar os bipes para os pontos de alerta. Selecione radar (por exemplo) aponte para um dos dois arquivos de áudio (aqueles do link acima). Claro, os arquivos devem ser inseridos na subpasta ui_igo9/audio. Se não tiver esta pasta na raiz de seu Primo, então crie uma (ou seja, a subpasta também). Se preferir, insira os arquivos na skin ou no data.zip, como achar melhor. Só isso. Agora um detalhe, como a configuração mais usada é para repetir o bipe até que a velocidade seja reduzida para o limite de velocidade, então esta frase, presente nos dois arquivos do link, será repetidamente até que a velocidade seja atingida. Caso se use a skin padrão, então é preciso configurar o sys.txt, setando o nome do arquivo no parágrafo ;S P E E D C A M - C A T : 0. Deixo aqui este parágrafo com comentários sobre as linhas e os possíveis ajustes que podem ser feitos. ; S P E E D C A M - C A T : 0 [speedcam_category:0] activated_spoken_type=speech ; valores: none, sound (arquivo .wav) e speech (somente TTS) activated_sound="Fixed_Camera" ; informar o nome de arquivo de áudio (se sound selecionado na linha acima) activated_speech="Speed camera," ; informar a frase para a voz TTS (se speech selecionado acima) activated_min_speech_repeat_delay=0 ; o valor -1 desabilita o recurso. Trata-se do atraso na repetição da fala approach_beep_distances=150 ; faixa operacional do bipe. approach_beep_spoken_type=speech ; valores: none, sound (arquivo .wav) e speech (somente TTS) approach_beep_sound="Fixed_Camera" ; informar o nome de arquivo de áudio (se sound selecionado na linha acima) approach_beep_speech="Speed camera," ; informar a frase para a voz TTS (se speech selecionado acima) overspeed_spoken_type=speech ; valores: none, sound (arquivo .wav) e speech (somente TTS) overspeed_sound="!sectionbeepB" ; informar o nome de arquivo de áudio (se sound selecionado na linha acima). Também pode-se usar o arquivo "Reduce_your_speed" (com voz gravada/natural). overspeed_speech="Reduce your speed." ; informar a frase para a voz TTS (se speech selecionado acima) overspeed_min_speech_repeat_delay=10 skin_first_sound_type=sound ; valores: none, sound (arquivo .wav) e speech (somente TTS) - ux Alert_Sounds 0, desabilita, 1 bipe padrão skin_first_sound="Fixed_Camera" skin_speed_sound_delay=120 skin_repeat_sound="Fixed_Camera" skin_repeat_distance=50 skin_off_sound="End_Fixed_Camera" min_frc=-1 use_road_speedlimit=1 ; o valor 0 mostra o limite de velocidade dado no arquivo speedcam.txt (ou outros txt) e o valor 1 mostra o limite de velocidade dado no mapa. Abração!

Nelson, a versão do Android não importa. Já testei estas vozes em uma CM com Android versão 2.3.4 e funcionou corretamente. O problema está nas linhas que citei em post anterior (pode haver mais, porém não tenho como testar ainda, farei isso em breve). Abração!

Nelson, acho que descobri a solução do problema que você está enfrentando com as vozes deste tópico (não permitir ajustes da voz TTS). Olhei as skins do Ultimate e vi que o Rafael alterou (ou manteve algo já existente e fora do padrão) uma diMka a1.3.3. Tem duas frases nestas skins Ultimate que estão fora do padrão diMka (não sei como está na diMka 1.3.3 original) e que não estavam presentes no dictionary.voice das vozes que disponibilizei. São elas: Low_Bridge="Altura limitada." RoadPoliceStation="Posto de polícia rodoviária," A primeira decorre do trabalho do Fidelis sobre o ponto de alerta altura limitada, mas o usual é Low Bridge, sem o símbolo "_" (caixa baixa). A segunda linha não sei de onde saiu, nunca vi em skin alguma. Ou seja, se existir uma linha diferente em uma skin, módulo ux, etc. que não esteja presente no dictionary.voice, então o Primo informa que a voz selecionada não é uma autêntica TTS Pro e que outra deve ser selecionada. Não é isso, na verdade, o que se deve fazer é inserir as linhas faltantes no arquivo dictionary.voice de cada voz TTS, uma por uma. Pode ser que existam outras linhas além das duas acima na skin Ultimate, mas acredito que são apenas estas. Fiz testes rápidos e o menu de configurações da TTS foi ativado, porém não fiz outros testes. Aqueles que estão tendo o mesmo problema com a skin Ultimate para Primo Android poderão inserir as duas linhas citadas acima no arquivo dictionary.voice de uma dada voz TTS e fazer testes. Se tudo ok, fazer o mesmo com as demais vozes. Aliás, peço para reportar sucesso ou insucesso, assim ganham todos. Quando for disponibilizar novas atualizações das vozes, então já seguirá com estes novos ajustes. Abração!

Caro amigo Thoth, obrigado pela informação de falha de pronúncia. Já corrigi aqui e em breve disponibilizarei os arquivos atualizados. Os novos também contemplarão as alterações que sugeri ao amigo Coelko e que funcionaram bem (ajustes no info.ini das vozes para Primo 2.4 Android). Quanto ao problema do amigo Nelson ainda não tenho uma solução. Nelson, você poderia me passar um link contendo a skin que apresenta problemas com a voz TTS? Não tenho dispositivo com a resolução do pacote que você está usando, mas certamente o problema deve estar na skin (uma ou outra, como o Coelko disse). Muito provavelmente é uma frase ou outra que está faltando nas vozes, mas não é difícil resolver tendo a skin em mãos. Abraços aos amigos!

Pessoal, estou terminando de atualizar o branding, deixando-o em conformidade com os novos POI. Em breve irei atualizar os links do primeiro post, avisando aqui, através de outro post. Os arquivos já estão prontos, apenas em fase de testes. []'s .XA.

Kuragato, o problema não está nos arquivos aqui disponibilizado. Se as frases estão incompletas, então a falha está no engine de voz, isto é, aquele mecanismo de síntese de voz que é instalado e selecionado nas configurações do próprio Android. Sugiro que você selecione outro engine de voz no Android e faça testes. Se não funcionar, desinstale o mecanismo de voz e instale novamente. Acredito que no próprio pacote que está usando (Ultimate) você tenha os engines disponíveis. É isto que você precisa verificar. Abraços.

Caro amigo Nelson, quando o lang (especificamente o dictionary.lang) não contém uma dada frase traduzida, então o navegador (qualquer um da família iGO) apresenta tal frase no idioma original (na maior parte, em inglês, mas existem outros casos também). Já no caso das vozes o problema é mais delicado: se uma skin, módulo ux, etc. não tiver tradução no arquivo dictionary.voice (veja, não é tratamento de pronúncia errônea, mas sim comandos básicos), então o navegador "alega" que a voz não é uma TTS de fato. No caso das vozes, simplesmente não dá para deixar frases típicas sem tradução, pois o erro vai aparecer. Bem, no caso das vozes deste tópico, elas são consequências de trabalhos de várias pessoas, onde eu apenas aproveitei parte, fiz correções de traduções e acrescentei muita coisa. Então elas representam o acúmulo de trabalhos em traduzir para textos (e leitura do engine TTS) material de várias ux, skins, etc. Mas algo pode ficar de fora, claro. E problemas surgirão. A questão pior surge quando alguém modifica uma skin ou módulo ux e usa uma frase fora do padrão. Explico: nativamente o Primo e o Nextgen, por exemplo, trabalham com frases em inglês e usa lang e voices para traduzir e "fazer o resto". Se a coisa for assim (em inglês), não dá erro algum. A frase de texto ficará em inglês (basta corrigir no lang) e a TTS tentará falar uma frase, em inglês, mas através do engine do idioma selecionado (português BR, por exemplo). Mas se a frase for em outro idioma, a voz falha (apesar de o texto, no caso o uso do lang, não gerar problema). Problema: algumas pessoas inseriram comandos em skins em ux aqui em nosso país, sem saber deste problema, mas usando o português BR. E como resolver o problema das vozes? Inserir uma ou mais linha no dictionary.voice em português BR com a tradução para o... Português BR!!! É mole a criatividade destes sujeitos??? Insisto, se em inglês, sem problema, mas em qualquer outro idioma (só as vozes), sem chances! E para piorar o cenário, se uma frase for usada em uma skin e em outra a frase for ligeiramente modificada (por exemplo, trocar uma letra maiúscula por minúscula ou vice-versa), então nova frase terá que ir para o dictionary.voice. Sinto lhe dizer, mas este deve ser o problema que você está enfrentando. Porém não afirmo que é. A questão que resta é como saber qual é a(s) frase(s) faltante(s) no conjunto que você está usando. Isto implica em analisar arquivo por arquivo e localizar uma frase ligeiramente diferente e que terá que ir para o dictionary.voice de cada uma das vozes. E não existe um programinha automatizado para fazer isso, é no braço mesmo. Mas para que você possa entender mais a lógica deste mundo GPS (do qual sempre fui muito crítico): na ânsia de fazer pacotes espetaculosos e não ser copiado por quem quer que fosse (o que é legítimo!), algumas pessoas começaram a dificultar certas coisas, mas de maneira tal que apenas pacotes completos disponibilizados por elas funcionariam como o anunciado/esperado. O problema é que uma interrupção destes pacotes feitos por determinada pessoa é que eles não aceitaram modificações "por conta própria", pois algo poderá deixar de funcionar. Acredito que este seja o seu caso. Não é defeito nas vozes, mas muito provavelmente o uso de um pacote que foi originalmente modificado para evitar cópias (e isto sempre houve) e que não está mais aceitando modificações através de novas vozes, porque algo ficou de fora (ou seja, o autor queria que fosse assim. Pegava uma voz, por exemplo, modificava ligeiramente o lang e a voz de alguém, deixava no pacote final e tudo funcionava muito bem. Passado um tempo, sem atualização continuada, problemas começam a surgir). Por fim, caro amigo: se uma TTS modificada por mim não está sendo reconhecida como uma autêntica TTS, então é porque tem outras coisas nos pacotes usados que impedem. E eu não sei o que fazer, pois não tenho acesso a detalhes de tudo o que foi feito por aí. O que posso garantir é que tudo o que conheço e usei, nem sempre adotando com uso diário, está aí contemplado e plenamente funcional (sim, pode haver erros, mas não do tipo citado). Se desconfiar de algo específico (skin, módulo ux, data.zip, o que for, basta me enviar uma cópia para estudar o caso e ver se consigo resolver o problema). Grande abraço!!!