HTTP Response의 TextStyle에 format 정보를 추가해주세요
Closed this issue · 12 comments
PRINT에는 접사에 따라서 좌/우측 정렬이나 개행 여부 등 문자열의 위치 정보가 갈리는 것을 확인했습니다.
하지만 현재 HTTP response는 콘솔에 출력되는 내용을 그대로 출력하는 중이라 개행 여부나, 정렬 방향에 대한 자세한 정보 없이 공백 등으로 이미 포매팅된 스트링만 제공되고 있어, 클라이언트 측에서 반응형 UI를 적용하기 어려운 상황입니다.
해당 부분을 TextStyle에 추가해 주셨으면 합니다.
PRINTC는 이미 설정에(emuera.config) 행마다 몇개가 출력될지, 어느 크기로 패딩을 할지가 정해져 있어서 UI단에서 정보를 알아도 바꿀수 있는건 없고요
개행여부는 무엇을 말하는건가요?
개행여부는 무엇을 말하는건가요?
아마 PRINTC 개행을 말하신거 같네요
PRINTC 출력 방법을 임의로 수정하는것의 단점을 생각해 봤는데
단순히 바둑판처럼 배열된 PRINTC 버튼들은 어떻게 출력하던지 상관없을거 같지만 밑의 예시처럼 정렬이 칸단위로 맞는걸 전제로해서 표처럼 만들어진건 임의로 수정하면 깨질 가능성이 높습니다
---------------
| [0] 버튼 |
방금 emuera.config을 확인해서 PRINTC 관련 항목이 있는 것을 확인했습니다.
그러면 해당 상황은 그러면 PRINT(L)C 자체에는 개행 기능이 없으나 화면의 너비를 초과해서 생기는 개행이 맞는 건가요?
그렇다면 config에는 한 행의 문자 수가 아니라 단순 윈도우 크기를 지정하고 있으니 UI측에서 자유롭게 개행을 진행해도 되는 것이 맞는 것 같은데, 그렇다면 이쪽에서는 문제가 없을 것 같네요.
다만 이제 정렬 부분은 UI측에서 관리하면 monospace가 아닌 폰트에 대해서도 잘 맞춰줄 수 있을 것 같은데 공백으로 미리 포매팅하는 대신 PRINTC계열의 출력임을 알려주는 것도 좋을 것 같습니다.
추가로 config 역시 json 형태로 얻어오고 변경하는 HTTP endpoint를 추가할 계획이 있으신가요?
그러면 해당 상황은 그러면 PRINT(L)C 자체에는 개행 기능이 없으나 화면의 너비를 초과해서 생기는 개행이 맞는 건가요?
너비가 초과돼서 개행이 생기는건 없습니다 printc가 PRINTCを並べる数만큼 반복되면 개행됩니다(현재는 하드코딩 돼있지만 나중에는 설정에서 읽을 예정)
추가로 config 역시 json 형태로 얻어오고 변경하는 HTTP endpoint를 추가할 계획이 있으신가요?
컨피그는 그렇게 다루는게 맞을거같네요 다만 우선순위는 아직 낮습니다
그러면 해당 상황은 그러면 PRINT(L)C 자체에는 개행 기능이 없으나 화면의 너비를 초과해서 생기는 개행이 맞는 건가요?
너비가 초과돼서 개행이 생기는건 없습니다 printc가
PRINTCを並べる数만큼 반복되면 개행됩니다(현재는 하드코딩 돼있지만 나중에는 설정에서 읽을 예정)
이게 저도 config을 봤는데 YM에서 그 값을 조절해도 버튼 개수들이 달라지지 않아서 그런데 PRINTFORMLC는 PRINTC 설정에 영향을 받지 않는건가요?
그러면 해당 상황은 그러면 PRINT(L)C 자체에는 개행 기능이 없으나 화면의 너비를 초과해서 생기는 개행이 맞는 건가요?
너비가 초과돼서 개행이 생기는건 없습니다 printc가
PRINTCを並べる数만큼 반복되면 개행됩니다(현재는 하드코딩 돼있지만 나중에는 설정에서 읽을 예정)이게 저도 config을 봤는데 YM에서 그 값을 조절해도 버튼 개수들이 달라지지 않아서 그런데 PRINTFORMLC는 PRINTC 설정에 영향을 받지 않는건가요?
Emuera에서 말인가요?
그러니까 제가 지금 정확하게 이해를 못하겠는 부분이
와
의 차이가 어떻게 발생하는건지가 궁금하네요
그러면 해당 상황은 그러면 PRINT(L)C 자체에는 개행 기능이 없으나 화면의 너비를 초과해서 생기는 개행이 맞는 건가요?
너비가 초과돼서 개행이 생기는건 없습니다 printc가
PRINTCを並べる数만큼 반복되면 개행됩니다(현재는 하드코딩 돼있지만 나중에는 설정에서 읽을 예정)
일단 정리해서, 이게 lines로 들어오는 각 항목은 그 항목 사이에 개행이 된다는 정보로 들어오는 상황이라면
이런 식으로 각 버튼들이 전부 개행이 된 것처럼 표현이 되는 문제가 있다고 표현을 정정하겠습니다. 각 버튼들을 취합해서 같은 라인에 보이는 버튼들은 한 line에 묶어서 보내주는 것이 맞지 않나 생각합니다.
그러니까 제가 지금 정확하게 이해를 못하겠는 부분이
와
의 차이가 어떻게 발생하는건지가 궁금하네요
제가 Emuera 소스를 다시 뒤져봤는데 해당 설정은 일부 상황 정확히는 PRINT_PALAM, PRINT_SHOPITEM 커맨드랑 TRAIN에서 커맨드 목록 표시할때만 사용하네요
일반적인 상황에선 PRINTC로는 개행이 안되는게 맞는거 같습니다
Emuera에서 너비가 넘어가면 개행되는거처럼 wrapping 하는건 런타임쪽에서 처리 안하고 프론트엔드쪽에서 다루는게 좋을것 같네요
네 그럼 일단 train 안에서는 PRINTC 설정 값에 따라서 버튼을 같은 라인에 묶고, 그 외의 경우에는 PRINTL 등의 개행이 발생할 때까지 전부 같은 라인으로 묶어줘서 프론트에서 처리시키는 쪽이 괜찮아보입니다.