- HTML 55.6%
- JavaScript 28.2%
- Python 11.9%
- CSS 4.3%
65c09813c3
Agora, além de ser possível registrar sinais alomórficos, eles aparecem na página de detalhes do sinal |
||
|---|---|---|
| .vscode | ||
| node_modules | ||
| patterns | ||
| public | ||
| .gitignore | ||
| db.js | ||
| getHandshapesFromSignbank.py | ||
| image.png | ||
| LICENSE | ||
| main.html | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| rotinaInserçãoSinal.ktr | ||
| server.js | ||
libras_signwriting_dictionary
Projeto pessoal de um dicionário de Libras escrito totalmente em signwriting, com suporte a SWU (SignWriting in Unicode).
O signwriting foi criado por Valerie Sutton em 1974 para ser uma forma fácil, porém expressiva, de descrever um sinal em todos os seus 5 parâmetros (configuração de mão, movimento, orientação da palma,ponto de articulação e expressões não manuais).
No início o signwriting era gerado através da edição da sobreposição de formas geométricas e geração de imagens (que no começo eram pixeladas, mas se tornaram vetoriais). Entretanto, chegou-se à conclusão de que, por ser o signwriting uma forma de escrita, deveria ser possível escrevê-lo através de uma fonte (como ocorrem com as demais formas de escrita)
Através de um trabalho conjunto de Stephen E. Slevinski Jr., em colaboração com o projeto Sutton SignWriting, foram disponibilizados, em 2010, milhares de símbolos do ISWA 2010 (formas de mão, movimentos, expressões faciais) em formato TrueType.
Em seguida foram feitas várias tentativas de integração com o formato UTF, como pode ser visto neste texto:
Dentre essas tentativas, pode-se destacar:
Formal SignWriting in ASCII (FSW): lançado em Janeiro de 2012, utiliza caracteres do subconjunto ASCII. SignWriting in Unicode (SWU): lançado em Outubro de 2016 e oficialmente submetido ao Comitê Técnico do Unicode em Julho de 2017, ainda não faz parte do padrão Unicode.
Ao analisar ambas e, apesar do SWU ainda não fazer parte do padrão Unicode, tudo indica que isso tenderá a ocorrer futuramente. E é uma alternativa mais segura apostar em uma forma de escrita que utilize Unicode, do que em uma que utilizada subconjutno ASCII.
O dicionário apostará no SWU para gerar um dicionário de Libras 100% em Libras, onde todas as palavras sejam escritas em signwriting e explicadas por definições escritas unicamente em signwriting. O objetivo desse projeto é ampliá-lo para que pessoas fluentes em libras possam auxiliar em sua criação, de modo eliminar a ocorrencia do portuguẽs sinalizado, uma vez que Português e Libras são idiomas distintos (e isso é algo que deve ser deixado sempre claro a todos que participarem desse projeto)
Outro ponto importante é foi criado o SignBank, que é um banco de dados de sinais (em signwriting) que permite identificar o SWU de cada sinal inserido.
O link para o SignBank da Libras pode ser acessado abaixo: Essa é uma ferramenta interessante para ser utilizada para popular o banco de dados desse projeto.
https://www.signbank.org/signmaker/#?ui=ptBR&dictionary=bzs
No momento de criação desse projeto, havia três projetos github (que também são pacotes npm) que poderiam ser utilizados:
https://github.com/sutton-signwriting/font-ttf
https://github.com/slevinski/signwriting_2010_fonts
https://github.com/sutton-signwriting/core
Através da análise das funcionalidades dos três, pude perceber que o signwriting core não possui a funcionalidade de gerar um símbolo visual através de uma string SWU, que é o que será necessário para esse projeto. Essa funcionalidade no existe no pacote node font-ttf do signwriting, através do qual é possível carregar a fonte do signwriting e fazer essa exibição.
Levando isso em conta, o projeto será alterado para que não utilize mais o signwriting core, limitando-se a utilizar o pacote signwriting font-ttf.
Já o pacote signwriting_2010_fonts não chegou a ser estudado a fundo. Mas como o font-ttf já foi suficiente para o propósito, não houve motivo para trocá-lo.
Uma parte importante do projeto é entender como é formada a string do SWU. Apesar do SignBank ser capaz de criar essas strings de forma automatizada, é importante entender como ela é formada para que seja possível criar símbolos de negação de forma automática (considerando que a grande maioria dos verbos não possui um sinal específico para sua negação, utilizando de expressões faciais para negar).
Contudo,a documentação do SWU é precária, pois todos os tutoriais que explicam sobre o tema se limitam a detalhar o funcionamento do FSW, explicando o mínimo possível sobre o SWU. Desse modo, o entendimento dessa string se dará por análise do comportamento da geração de strings do signbank, além de análise do código fonte.
No código fonte do font-ttf, é possível encontrar essa relação entre os marcadores do FSW e do SWU:
'𝠀': 'A' -> Sequence Marker '𝠁': 'B' -> Signbox Marker (0) '𝠂': 'L' -> Left Lane Marker (-1) '𝠃': 'M' -> Middle Lane Marker (0) '𝠄': 'R' -> Right Lane Marker (1)
Ou seja, o marcador 𝠀(A) marca a sequência de todos os símbolos que foram utilizados no sinal, na ordem em que foram inseridos. Os demais marcadores marcam posições do signbox:
Y Axis
| 250
|
|
|
|
|
X Axis | -----------+------------ 250 | 749 | | | | | | 749
A string SWU é separada em duas partes:
1ª PREFIXO TEMPORAL: É uma parte opcional, mas muito importante para fins de ordenamento. O prefixo temporal vêm no início da string, após o marcador 𝠀, e consiste em uma lista de símbolos importantes seguindo alguma teoria de ordenamento. A que é considerada a mais produtiva se chama SignSpelling Sequence theory e foi criada pela Valerie Sutton:
" A temporal prefix is structured as a series of beginning handshapes, followed by transitional movements and dynamics that lead to the next set of handshapes. This pattern continues until the end of the sign. The last section of the temporal prefix should contain symbols of type "head", "trunk", and 'limb'. Detailed location symbols of type 'location' can be used in atemporal prefix, but are rarely (if ever) needed for general writing."
Temporal Prefix Tokens
+================+===================================+ | Token Patterns | Description | +================+===================================+ | A | Sequence Marker | +----------------+-----------------------------------+ | w | Writing BaseSymbols | +----------------+-----------------------------------+ | s | Detailed Location BaseSymbols | +----------------+-----------------------------------+ | i | Fill Modifiers | +----------------+-----------------------------------+ | o | Rotation Modifiers | +----------------+-----------------------------------+ | (A([ws]io)+)? | An optional temporal prefix to be | | | used as a prefix for a Signbox | +----------------+-----------------------------------+
2ª SPATIAL SIGNBOX: É a parte obrigatória, formada por símbolos e suas coordenadas X e Y. O marcador utilizado é geralmente o 𝠃(M), que mostra que o ponto de referência (a partir do qual são geradas as coordenadas) fica 100% no centro.
Por exemplo, se eu criar o seguinte sinal no SignBank, utilizando 4 configurações de mão em posições distintas:
Isso criará a seguinte string SWU:
𝠃𝧚𝦳𝠳𝡚𝧄𝡾𝡆𝥶𝧅𝦕
Em seguida, se eu alterar a posição do elemento um pouco, a string SWU pode se tornar:
𝠃𝧚𝦳𝠳𝡚𝤫𝣗𝡆𝥶𝧅𝦕
Ou seja, os símbolos como 𝧚𝦳 e 𝠳𝡚 que aparecem antes das configurações de mão, representam coordenadas. Em FSW eles são exibidos como números. Mas em SWU, todos os elementos, incklusive números, são convertidos em caracteres UTF-8.
Apesar de existirem mais marcadores, aparentemente só estão sendo utilizados os marcadores 𝠀': 'A' e 𝠃': 'M' no SignBank. Mesmo que seja pego um sinal extremamente complexo, somente esses marcadores são vistos:
𝠀𝠃𝤴𝥗𝣳𝣊𝤇𝣫𝣦𝣫𝣘𝣲𝤊𝤂𝤛𝣰𝣷𝤂𝣵𝤕𝣥𝤻𝤀𝥆
Um detalhe importante ao criar sinais no Signbank é que o prefixo temporal não é criado junto, às vezes. Por conta disso, é possível encontrar sinais salvos com prefixo temporal e outros sem o prefixo temporal. Para melhor gerenciamento dessas situações, é interessante construir o banco de dados para separar o prefixo temporal do bounding box.
Ou seja, swu_string = temporal_prefix + spatial_signbox
Imagens SVG:
Nesse projeto, as imagens SVG serão criadas para explicar a iconicidade dos sinais. Por exemplo, para o sinal de casa será criado uma imagem cujo telhado terá a cor #f02b11, enquanto os demais elementos terão cores cinzas/brancas como #c7c3b9, #8d979e, #b5ac9e, #7b7d80, #bfb1af ... Ou seja, a imagem mostrará que a iconicidade do sinal está relacionada ao formato do telhado. Para alguns sinais como "casa" essa icoinicidade é óbvia. Contudo, há casos em que ela se torna mais difícil de assimilar.
https://www.flaticon.com/br/icone-gratis/casa_609803 https://www.adobe.com/express/feature/image/convert/png-to-svg https://colorkit.co/change-svg-color/