Taki tam mały błąd dotyczący przerwania zliczania linii kodu na forum.
Zrzut jest dla tego tematu https://4programmers.net/Forum/C_i_C++/352952-zamiana_kolejnosci_danych_w_pliku_txt
2
5
Tema już był poruszany kilka razy.
Ogólnie to problemem jest to, że się lekko rozjeżdża wysokość numerów linii i samego kodu. Przy kilkunastu/kilkudziesięciu liniach to jedynie widać niewielki rozjazd. Ale przy kilkuset to się dzieje tak, jak masz na obrazku.
Chyba nie jest tak, jak napisałeś - że zliczanie linii się przerywa. Podejrzewam, że jakbyś policzył linie kodu to będzie ich tyle, co numerków po lewej. Po prostu - kolumna z numeracją jest niższa od fragmentu z tekstem.
1
Potwierdzam – rozjeżdża się wysokość linii numeracji z wysokością linii samego kodu. Link do ostatniej dyskusji na ten temat, jaką pamiętam: Wymiana Geshi na Prism
0
Czy ktoś w ogóle dorzucił zadanie na GitHub, czy problem był tylko omawiany i nic więcej? ;)
0
Nie wiem czy dorzucił, ale w tamtym wątku było @Marooned i @Adam Boduch - więc odpowiednie osoby wiedzą o problemie.
0
Czy ktoś ma pomysł w którym miejscu szukać problemu? Nie mogę coś dojść do selektora CSS który to powoduje ...
1
Jakbym mógł odtworzyć ten problem, to bym poszukał, ale... u mnie działa ;-)
Chyba tylko Linux ma problemy, jeśli dobrze kojarzę?
2
Chyba tylko Linux ma problemy, jeśli dobrze kojarzę?
Używam openSUSE Leap 15.2, Firefox 78.11.0esr (64 bity) i Google Chrome Wersja 91.0.4472.101 (Oficjalna wersja) (64-bitowa) i na obu problem występuje. Co ciekawe na Androidzie 11 z Firefox w wersji 89.1.1 problemu nie ma.
Po pracy mogę sprawdzić na openSUSE Tumbleweed z Firefox w wersji 89.
1
Marooned napisał(a):
Jakbym mógł odtworzyć ten problem, to bym poszukał, ale... u mnie działa ;-)
Chyba tylko Linux ma problemy, jeśli dobrze kojarzę?
Nope - właśnie odkryłem, że na znienawidzonym przez @cerrato OS (#pdk) też nie działa i zliczanie linii też się rozjeżdża. Chrome 91
5
Marooned napisał(a):
Chyba tylko Linux ma problemy, jeśli dobrze kojarzę?
Czyli przez 20 lat nic się nie zmieniło.
Jak znam życie, to gdzieś na jakimś forum ktoś ma zmodyfikowane sterowniki do karty sieciowej rozwiązujące ten problem. Ewentualnie trzeba odłączyć myszkę BT i użyć kablowej, to zawsze pomaga.
2
Adam Boduch napisał(a):
Czy ktoś ma pomysł w którym miejscu szukać problemu? Nie mogę coś dojść do selektora CSS który to powoduje ...
Tak jak pisałem tutaj – wyłączenie stylu font-family: Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace dla znacznika selektora <pre>pre w tym arkuszu zdaje się rozwiązywać problem. Sprawdzone dla Firefox 89. Teraz wypadałoby sprawdzić dla innych przeglądarek. I jeśli zadziała, to takim szybkim obejściem mogłoby być wyłączenie tego stylu i spróbowanie znalezienia czegoś, co go zastąpi. Jeśli w ogóle jest potrzebny, bo nie wiem.
PS Sprawdzić dla innych kombinacji czcionek, systemów i przeglądarek, oczywiście, a nie samych przeglądarek. ;) System, na którym sprawdzałem: Linux.
1
Umnie dziala win 10, Edge Wersja 91.0.864.48 (Oficjalna kompilacja) (wersja 64-bitowa)
3
Poza przypadkiem opisanym przeze mnie powyżej, w Firefoxie 89.0 na Linuxie problem wydaje się także nie występować, jeśli ustawić opcję browser.display.use_document_fonts (about:config) na 0 (zamiast 1; żadnych styli nie wyłączałem w narzędziach deweloperskich). Nie wiem, do czego dokładnie w tej opcji odnosi się wyraz "document". Tutaj jej dokumentacja.
UPDATE Załączam przykładowy listing do celów testowych.
a
b
c
d
e
f
g
h
i
UPDATE2 Jeśli wartość 0 dla tej opcji oznaczałaby: "Nie używaj nigdy czcionek zdefiniowanych przez stronę", to problemem byłaby jakaś czcionka, którą 4p (Bootstrap?) specyfikuje, a która nie u wszystkich występuje (tj. tam, gdzie występuje, ten "problem większych linii" się pojawia). PS Piszę "oznaczałaby", a nie "oznacza", bo nie jestem pewien, jak napisałem, do czego odnosi się wyraz "document".
0
@Silv: ten twój listing przy tym parametrze na 1 się rozjeżdża:
to problemem byłaby jakaś czcionka, którą 4p (Bootstrap?) specyfikuje, a która nie u wszystkich występuje
Jaka to czcionka? Może sobie "dogram" i zobaczę czy to ponownie występuje?
0
Zgodnie z tym, co napisałem, skoro się rozjeżdża; dla wartości 1 Firefox pobiera jakąś czcionkę z 4p (czcionkę Bootstrapa?), a dla wartości 0 nie pobiera (używa lokalnych czcionek). Jeszcze nie odkryłem, która to czcionka.
UPDATE Dla Chromium 90.0.4430.212 (Developer Build) na Linuxie wyłączenie tego stylu, o którym pisałem wyżej w kontekście Firefoxa, także zdaje się rozwiązywać problem.
2
Można wyłączyć chwilowo tę regułę by otrzymać błąd - rozjazd w pionie:
code, kbd, pre {
font-family: SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,monospace;
}
dzięki temu można było popracować nad tematem. Wygląda na to, że dodanie
pre[class*="language-"].line-numbers > code { /* istniejący selektor */
display: block;
}
Naprawia temat. Nie zauważyłem, by coś psuło, ale to by trzeba było się upewnić (nie tylko na forum, ale i na uBlogu)
1
Marooned napisał(a):
Można wyłączyć chwilowo tę regułę by otrzymać błąd - rozjazd w pionie:
code, kbd, pre { font-family: SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,monospace; }
Ale ta reguła u mnie jest nadpisywana?
PS Ach, już chyba wiem, Ty mówisz o regule dla code, a ja dla pre. Tak mi się wydaje. Na zrzucie powyżej jest różnica w odcieniach szarego dla selektorów poszczególnych elementów. Nie wiem, czy to o to chodzi.
PS2 Czyli być może problem polega na tym, że dla elementu code są wyspecyfikowane (przez Bootstrapa?) inne czcionki niż dla elementu pre (numery linii są w elemencie pre, ale nie w code, a kod jest w elementach code oraz pre). @Marooned Ale co ma do tego wszystkiego display: block;?
0
Rozjeżdża się jak nastąpi fallback do fonta Courier New - dla innych działa ok. Można wywalić Courier New z font-family
Działa też gdy się ustawi dla code line-height: 18px lub cokolwiek większego od 1.5em
1
W font-family dla selektora pre są następujące wartości: Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace.
W font-family dla selektora code, kbd, pre są następujące wartości: SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,monospace.
Po wyrzuceniu z code samej wartości Courier New nic się nie zmienia; tak samo po wyrzuceniu samej wartości Liberation Mono. Natomiast po wyrzuceniu obu wysokości linii na oko wydają się zgadzać. Testowane na Chromium 90.0.4430.212 (Developer Build) na Linuxie.
PS Co ciekawe, problem wydaje się nie występować także po wyrzuceniu samej wartości monospace dla pre (wszystkie inne wartości dla pre zachowane). (Testowane na Chromium 90.0.4430.212 (Developer Build) na Linuxie).
PS2 Poprawiłem nazwę selektora – oczywiście code, kbd, pre, a nie code.
0
@.andy: mógłbyś dodać ręcznie ten display: block u siebie i zobaczyć, czy to Ci naprawia?
Problem jest dlatego, że w <code> jest przerwa w pionie pomiędzy liniami, a w <span> zliczającym linie tej przerwy nie ma. I ta przerwa właśnie się kumuluje.
2
dodanie rozwiązuje problem.
0
Ciekawe skąd ten problem wynika. Czy to Bootstrap nadpisuje jakieś właściwości?
Do code nie możemy dodać display: block bo to musi być element inline .
0
Dlaczego musi? Wygląda, jakby zajmował całą szerokość rodzica, nie kojarzę, by koło code coś obok stało.
Poza tym to code jest bezpośrednio w pre, które domyślnie jest elementem blokowym. To pre ma w sobie tylko code oraz span do zliczania linii, które ma position: absolute, więc mu nie szkodzi.
0
Ok, rzeczywiście możemy dodać tę właściwość w pre code. Bo jak zmienimy w w code to będzie coś takiego:
0
ekhm ;-)
Marooned napisał(a):
dzięki temu można było popracować nad tematem. Wygląda na to, że dodanie
pre[class*="language-"].line-numbers > code { /* istniejący selektor */ display: block; }Naprawia temat. Nie zauważyłem, by coś psuło, ale to by trzeba było się upewnić (nie tylko na forum, ale i na uBlogu)
pre[class*="language-"].line-numbers > code :)
0
Na Linuksie tego problemu nie mam, ale zarówno renderowanie jak i czcionki są z Windows, bo domyślne chyba projektował psychopata. Wszystko wygląda tak, jak na Windows, to pewnie jakiś problem czcionek.
0
@Marooned: To ja już się pogubiłem. Czemu usunięcie czcionek wydaje się pomagać tak samo, jak owa deklaracja display: block?
0
Na Androidzie jest też wszystko ok:
3
Ok, czyli można powiedzieć, że poprawka @Marooned pomaga :) W takim razie robię commit. Dzięki!
1
@Adam Boduch: Niezależnie od tej poprawki, czy można by ujednolicić zestawy czcionek dla elementów <pre> oraz <code>? Wszystko jedno, czy <pre> otrzyma zestaw czcionek <code>, czy odwrotnie.